From: Trent Piepho <firstname.lastname@example.org>
To: Sascha Hauer <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: Thu, 4 Nov 2021 14:40:08 -0700 [thread overview]
Message-ID: <CAMHeXxOfPsNPHzewPtUKZJ=7bR9ew-hanrokiBF0Cst_oQkcqQ@mail.gmail.com> (raw)
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.
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
next prev parent reply other threads:[~2021-11-04 21:42 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 [this message]
2021-11-08 9:10 ` Sascha Hauer
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