From: Xavier Drudis Ferran <xdrudis@tinet.cat>
To: Marek Vasut <marex@denx.de>
Cc: Xavier Drudis Ferran <xdrudis@tinet.cat>,
u-boot@lists.denx.de, Simon Glass <sjg@chromium.org>,
Philipp Tomsich <philipp.tomsich@vrull.eu>,
Kever Yang <kever.yang@rock-chips.com>,
Lukasz Majewski <lukma@denx.de>,
Sean Anderson <seanga2@gmail.com>
Subject: Re: [PATCH v3] arm: dts: rockchip: rk3399: usb: ehci: Fix EHCI probe in rk3399 to access peripherals by USB 2.
Date: Thu, 8 Dec 2022 22:00:49 +0100 [thread overview]
Message-ID: <Y5JQgSnLYZS+/6DJ@localhost> (raw)
In-Reply-To: <b247d490-55b8-64da-9068-6717eaf068a0@denx.de>
El Thu, Dec 08, 2022 at 09:12:08PM +0100, Marek Vasut deia:
> On 12/8/22 17:53, Xavier Drudis Ferran wrote:
>
> [...]
>
> > +++ b/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
> > @@ -7,7 +7,7 @@
> > */
> > #include <common.h>
> > -#include <clk.h>
> > +#include <clk-uclass.h>
> > #include <dm.h>
> > #include <asm/global_data.h>
> > #include <dm/device_compat.h>
> > @@ -168,6 +168,9 @@ static struct phy_ops rockchip_usb2phy_ops = {
> > .of_xlate = rockchip_usb2phy_of_xlate,
> > };
> > +static struct clk_ops rockchip_usb2phy_clk_ops = {
> > +};
>
> Is this empty structure needed ? Why ?
>
> Either it shouldn't be here, or it should implement some callbacks, like
> clock enable/disable ?
>
I tried without it but it gave me a runtime error. I think I have the
log somewhere if you want to see it. It looked like a null pointer
dereference at first sight. I just added it and it got fixed. I
didn't research what the failing functions were trying to do.
Or is this a common case and there's some null_clk_ops() function or
macro magic or something somewhere ?
The thing is nobody is using this clk in u-boot. It's just its phandle
in a clock phandle list that ehci-generic.c happens to use in bulk. So
the default implementation seems to be enough to allocate, enable and
release it in bulk with its clk set. Or at least to call the functions
without error.
As I have left it, it might not work if ever someone wants to use it.
But should I try to implement it so that it is usable ? How should I
test it ? Shouldn't we wait until someone has some real use for it ?
Linux spent sometime without it in the phandle list until William wu
discovered it was needed for suspend/resume, so u-boot may never need
it.
Or should I add a comment in the code ?
> Otherwise looks much better, thanks !
Thanks.
next prev parent reply other threads:[~2022-12-08 21:01 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-08 16:53 [PATCH v3] arm: dts: rockchip: rk3399: usb: ehci: Fix EHCI probe in rk3399 to access peripherals by USB 2 Xavier Drudis Ferran
2022-12-08 20:12 ` Marek Vasut
2022-12-08 21:00 ` Xavier Drudis Ferran [this message]
2022-12-08 22:50 ` Marek Vasut
Reply instructions:
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y5JQgSnLYZS+/6DJ@localhost \
--to=xdrudis@tinet.cat \
--cc=kever.yang@rock-chips.com \
--cc=lukma@denx.de \
--cc=marex@denx.de \
--cc=philipp.tomsich@vrull.eu \
--cc=seanga2@gmail.com \
--cc=sjg@chromium.org \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.