Re: [PATCH] phy: core: Make 'phy_optional_get' return NULL when not implemented

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Nov 04, 2021 at 02:40:08PM -0700, Trent Piepho wrote:
> 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.

In Linux phy_optional_get() returns NULL (which is a valid phy) when
a) there is no "phys" property
b) The phy os compatible to "usb-nop-xceiv"
c) The phy has a status = "disabled" property

All other errors are fatal.

When there is a phy specified in the device tree then it's mandatory
and failures in getting it must lead to an error. the "optional" in
phy_optional_get() is only meant for the "there is no phy specified in
the device tree" case, it's only a shortcut for

	if (is_there_a_phy_in_device_tree())
		phy = phy_get();
	else
		phy = NULL;

Once you interpret "optional" as something different you end up
returning NULL for cases where you really need a phy. Only you as a
human know that, in your special case, on your special board, there is a
phy specified, but it can do without initialisation. That's why I
suggested you should add a status = "disabled" property to the phy to
explicitly state that it can work without the phy. By making it explicit
you also document that you thought about the case and not just exploited
a heuristic in barebox.

Sascha

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/barebox



[Index of Archives]     [Linux Embedded]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux