From: Sascha Hauer <firstname.lastname@example.org>
To: Trent Piepho <email@example.com>
Cc: "Daniel Brát" <firstname.lastname@example.org>, email@example.com
Subject: Re: [PATCH] phy: core: Make 'phy_optional_get' return NULL when not implemented
Date: Mon, 8 Nov 2021 10:10:22 +0100 [thread overview]
Message-ID: <20211108091022.GK25698@pengutronix.de> (raw)
On Thu, Nov 04, 2021 at 02:40:08PM -0700, Trent Piepho wrote:
> On Thu, Nov 4, 2021 at 1:02 PM Sascha Hauer <firstname.lastname@example.org> 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 <email@example.com> 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 <firstname.lastname@example.org> 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
phy = phy_get();
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.
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
next prev parent reply other threads:[~2021-11-08 9:12 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-20 8:39 Daniel Brát
2021-11-01 9:00 ` Sascha Hauer
[not found] ` <CAMHeXxMJYC2q4Hs7zd9A=5-KsXyFUtTshMVoZZC2nJUah=LtjA@mail.gmail.com>
2021-11-01 19:04 ` Trent Piepho
2021-11-02 7:40 ` Sascha Hauer
2021-11-03 22:35 ` Trent Piepho
2021-11-04 20:02 ` Sascha Hauer
2021-11-04 21:40 ` Trent Piepho
2021-11-08 9:10 ` Sascha Hauer [this message]
2021-11-08 22:01 ` Trent Piepho
2021-11-11 13:09 ` Sascha Hauer
2022-03-03 9:53 ` Sascha Hauer
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox