On Thu, Nov 4, 2021 at 1:02 PM Sascha Hauer <sha@xxxxxxxxxxxxxx> wrote: > On Wed, Nov 03, 2021 at 03:35:08PM -0700, Trent Piepho wrote: > > On Tue, Nov 2, 2021 at 12:40 AM Sascha Hauer <sha@xxxxxxxxxxxxxx> wrote: > > > > > > On Mon, Nov 01, 2021 at 11:33:07AM -0700, Trent Piepho wrote: > > > > On Mon, Nov 1, 2021 at 2:01 AM Sascha Hauer <[1]sha@xxxxxxxxxxxxxx> wrote: > > > > > > > > > The phy is only optional as long as none is specified in the device > > > > > tree. When there is one specified then it's no longer optional. We can't > > > > > do the right thing here without checking the device tree. Given that > > > > > it's simple to enable CONFIG_GENERIC_PHY I think this is the way to go. > > > > > > > > But this force enables GENERIC_PHY when it's not needed. > > > > > > > > There are commonly many device nodes in Linux dts files that are not used > > > > by an enabled Barebox driver. It's normal to turn off a driver that might > > > > be or could be used. Is it necessarily an error if a phy is present in > > > > the dts but we don't wish to include support for it? > > > > > > We need to distinguish the cases "There is a phy specified, but the > > > reset defaults are good enough to go without a driver" and "There is a > > > phy specified and we need driver support for it". barebox can't know > > > this. > > > > Could we say that compiling barebox without CONFIG_GENERIC_PHY means > > the driver is not needed and compiling it with the driver means that > > is it? > > Please no. Enabling Kconfig options ideally gives you additional > features, but it should not break anything. Consider the case when you > need to enable CONFIG_GENERIC_PHY for something else like an LVDS phy or > whatever, you don't want to end up with broken USB support then and have > to choose whether USB or LVDS is working. I thought your goal was to prevent less experienced users from building a non-functional Barebox and then not understanding what they had done. Turning off a necessary driver and breaking USB while producing no warnings nor errors. But I now gather I was mistaken and this isn't really the problem. I think the specific situation you are concerned about is where: A) the dts does define a phy for usb B) This phy does not work in Barebox, e.g. no driver C) Despite B, USB will still operate with the desired level functionality without a working phy driver. With the patch and CONFIG_GENERIC_PHY disabled, we get a non-fatal return at step A and everything is good. But once enabled, we now get a fatal error at step B and this is not good. Could this be fixed by making the error at B non-fatal? This is more how Linux works here: errors that are non-fatal in Linux's phy_optional_get() path are fatal for Barebox. Let phy_optional_get return NULL for any error. Create a warning if it appears the error was not: "no phy defined in dts". But what if there really is an unexpected error with the PHY? We won't trigger the phy failure path in the driver! I think realistically, this is never going to make a difference for anyone. Either way, one gets an error message and non-functional usb. Does it really matter where the error comes from? > > Wouldn't it be easier to just delete the phy-names property to disable the phy? > > My point is that you sometimes start Linux with the barebox internal > device tree. We should then pass a device tree Linux can handle > properly. A barebox,status would just be ignored by Linux whereas a > status = "disabled" property or deleted phy-names property would disable > the phy for Linux as well. If phy_optional_get does not make an unsupported phy an error, then there isn't really a need to disable the phy anymore. _______________________________________________ barebox mailing list barebox@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/barebox
