Re: [PATCH 1/6] clk: Handle error pointers in clk_valid()
On Sat, Mar 04, 2023 at 01:54:12PM -0600, Samuel Holland wrote:
> On 2/20/23 13:42, Michal Suchánek wrote:
> > On Mon, Feb 20, 2023 at 10:57:17AM -0500, Sean Anderson wrote:
> >>
> >> On 2/20/23 05:46, Michal Suchánek wrote:
> >>> On Sun, Feb 19, 2023 at 11:59:34PM -0600, Samuel Holland wrote:
> >>>> Some clk uclass functions, such as devm_clk_get() and clk_get_parent(),
> >>>> return error pointers. clk_valid() should not consider these pointers
> >>>> to be valid.
> >>>>
> >>>> Fixes: 8a1661f20e6c ("drivers: clk: Handle gracefully NULL pointers")
> >>>> Signed-off-by: Samuel Holland
> >>>> ---
> >>>>
> >>>> include/clk.h | 2 +-
> >>>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>
> >>>> diff --git a/include/clk.h b/include/clk.h
> >>>> index d91285235f7..4acb878ec6d 100644
> >>>> --- a/include/clk.h
> >>>> +++ b/include/clk.h
> >>>> @@ -671,7 +671,7 @@ static inline bool clk_dev_binded(struct clk *clk)
> >>>>*/
> >>>> static inline bool clk_valid(struct clk *clk)
> >>>> {
> >>>> -return clk && !!clk->dev;
> >>>> +return clk && !IS_ERR(clk) && !!clk->dev;
> >>>> }
> >>>> int soc_clk_dump(void);
> >>>
> >>> Maybe it would be better to avoid the error pointers instead, there
> >>> should not be that many places where they are returned.
> >>
> >> This not quite the right way to phrase this. Instead, I would ask: where
> >> are places where the return value is not checked correctly? It's perfectly
> >
> > Pretty much everywhere where clk_get_parent is used outside of core code
> > absolutely no error checking is done.
>
> There are 105 uses of ERR_PTR in drivers/clk, mostly in CCF clock
> registration functions. There is also devm_clk_get() with about 30
> callers. Those mostly seem to have reasonable error checking; the error
> pointer ends up as the driver probe function's return value via PTR_ERR.
Yes, there are too many. clk_valid should check both.
Reviewed-by: Michal Suchánek
Thanks
Michal
Re: [PATCH 3/6] clk: Fix error handling in clk_get_parent()
On Sat, Mar 04, 2023 at 01:58:17PM -0600, Samuel Holland wrote:
> On 2/20/23 04:39, Michal Suchánek wrote:
> > On Sun, Feb 19, 2023 at 11:59:36PM -0600, Samuel Holland wrote:
> >> Do not return both NULL and error pointers. The function is only
> >> documented as returning error pointers.
> >>
> >> Fixes: 8a1661f20e6c ("drivers: clk: Handle gracefully NULL pointers")
> >> Signed-off-by: Samuel Holland
> >> ---
> >>
> >> drivers/clk/clk-uclass.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
> >> index 78299dbceb2..5bce976b060 100644
> >> --- a/drivers/clk/clk-uclass.c
> >> +++ b/drivers/clk/clk-uclass.c
> >> @@ -490,7 +490,7 @@ struct clk *clk_get_parent(struct clk *clk)
> >>
> >>debug("%s(clk=%p)\n", __func__, clk);
> >>if (!clk_valid(clk))
> >> - return NULL;
> >> + return ERR_PTR(-ENODEV);
> >>
> >>pdev = dev_get_parent(clk->dev);
> >>if (!pdev)
> >
> > Do we really need this?
> >
> > Who cares about the distinction?
> >
> > Just returning NULL on any error makes the code so much simpler and
> > easier to understand.
>
> I'm fine with returning only NULL, or only ERR_PTR(-ENODEV) as done
> later in the function, but returning both makes the error handling in
> callers more complicated for no benefit. It sounds like you would prefer
> I change the later ERR_PTR(-ENODEV) to NULL instead of this change? I
> can do that for v2.
I think NULL is easier to check, and so long as there is no meaningful
distinction between ERR_PTR and NULL we should converge towards NULL as
the single error return value.
Thanks
Michal
Re: [PATCH] pci: Fix device_find_first_child() return value handling
Hello,
On Sun, Jul 16, 2023 at 05:53:24PM +0200, Marek Vasut wrote:
> This function only ever returns 0, but may not assign the second
> parameter. Same thing for device_find_next_child(). Do not assign
> ret to stop proliferation of this misuse.
>
> Reported-by: Jonas Karlman
> Signed-off-by: Marek Vasut
> ---
> Cc: "Pali Rohár"
> Cc: Bin Meng
> Cc: Marek Vasut
> Cc: Michal Suchanek
> Cc: Simon Glass
> ---
> drivers/pci/pci-uclass.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
> index 8d27e40338c..6421eda7721 100644
> --- a/drivers/pci/pci-uclass.c
> +++ b/drivers/pci/pci-uclass.c
> @@ -545,9 +545,9 @@ int pci_auto_config_devices(struct udevice *bus)
> sub_bus = dev_seq(bus);
> debug("%s: start\n", __func__);
> pciauto_config_init(hose);
> - for (ret = device_find_first_child(bus, &dev);
> - !ret && dev;
> - ret = device_find_next_child(&dev)) {
> + for (device_find_first_child(bus, &dev);
> + dev;
> + device_find_next_child(&dev)) {
Sounds like you will need to remove the declaration of the now unused ret
variable as well.
More generally, what is the overall vision for these functions returning
always zero?
Should the return value be kept in case the underlying implementation
changes and errors can happen in the future, and consequently checked?
Should the return value be removed when meaningless making these
useless assignments and checks an error?
I already elimimnated a return value where using it lead to incorrect
behavior but here using it or not is equally correct with the current
implementation.
Thanks
Michal
Re: [PATCH] am33xx: ignore return value from usb_ether_init()
Hello,
On Wed, Aug 30, 2023 at 10:49:50PM -0400, Trevor Woerner wrote:
> In 2cb43ef1c223 ("usb: ether: Fix error handling in usb_ether_init") the error
> handling of usb_ether_init() was changed. Not a single other call site of this
> function checks its return value, therefore follow suit in the am33xx code.
then there is the question what point is there in having a return value
in this function at all.
Anyway, it's fine to not check the return value in the caller if there
is no use for the error.
Reviewed-by: Michal Suchánek
>
> Do not cause the boot to halt if the usb gadget ethernet initialization fails:
>
> initcall sequence 9ffdbd84 failed at call 808024b9 (err=-19)
> ### ERROR ### Please RESET the board ###
>
> Signed-off-by: Trevor Woerner
> ---
> arch/arm/mach-omap2/am33xx/board.c | 6 +-
> 1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/am33xx/board.c
> b/arch/arm/mach-omap2/am33xx/board.c
> index ecc0a592e993..8f772310a1a7 100644
> --- a/arch/arm/mach-omap2/am33xx/board.c
> +++ b/arch/arm/mach-omap2/am33xx/board.c
> @@ -270,11 +270,7 @@ int arch_misc_init(void)
> return ret;
>
> #if defined(CONFIG_DM_ETH) && defined(CONFIG_USB_ETHER)
> - ret = usb_ether_init();
> - if (ret) {
> - pr_err("USB ether init failed\n");
> - return ret;
> - }
> + usb_ether_init();
> #endif
>
> return 0;
> --
> 2.41.0.327.gaa9166bcc0ba
>
Re: [PATCH v3] dm: core: Do not stop uclass iteration on error
Hello,
On Sat, Sep 17, 2022 at 09:02:53AM -0600, Simon Glass wrote:
> Hi Michal,
>
> On Wed, 31 Aug 2022 at 11:44, Simon Glass wrote:
> >
> > Hi Michal,
> >
> > On Wed, 31 Aug 2022 at 01:39, Michal Suchánek wrote:
> > >
> > > Hello,
> > >
> > > On Tue, Aug 30, 2022 at 09:15:12PM -0600, Simon Glass wrote:
> > > > Hi Michal,
> > > >
> > > > On Tue, 30 Aug 2022 at 10:48, Michal Suchánek wrote:
> > > > >
> > > > > On Tue, Aug 30, 2022 at 09:56:52AM -0600, Simon Glass wrote:
> > > > > > Hi Michal,
> > > > > >
> > > > > > On Tue, 30 Aug 2022 at 04:23, Michal Suchánek
> > > > > > wrote:
> > > > > > >
> > > > > > > On Sat, Aug 27, 2022 at 07:52:27PM -0600, Simon Glass wrote:
> > > > > > > > Hi Michal,
> > > > > > > >
> > > > > > > > On Fri, 19 Aug 2022 at 14:23, Michal Suchanek
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > When probing a device fails NULL pointer is returned, and
> > > > > > > > > other devices
> > > > > > > > > cannot be iterated. Skip to next device on error instead.
> > > > > > > > >
> > > > > > > > > Fixes: 6494d708bf ("dm: Add base driver model support")
> > > > > > > >
> > > > > > > > I think you should drop this as you are doing a change of
> > > > > > > > behaviour,
> > > > > > > > not fixing a bug!
> > > > > > >
> > > > > > > You can hardly fix a bug without a change in behavior.
> > > > > > >
> > > > > > > These functions are used for iterating devices, and are not
> > > > > > > iterating
> > > > > > > devices. That's clearly a bug.
> > > > > >
> > > > > > If it were clear I would have changed this long ago. The new way you
> > > > > > have this function ignores errors, so they cannot be reported.
> > > > > >
> > > > > > We should almost always report errors, which is why I think your
> > > > > > methods should be named differently.
> > > > > >
> > > > > > >
> > > > > > > > > Signed-off-by: Michal Suchanek
> > > > > > > > > ---
> > > > > > > > > v2: - Fix up tests
> > > > > > > > > v3: - Fix up API doc
> > > > > > > > > - Correctly forward error from uclass_get
> > > > > > > > > - Do not return an error when last device fails to probe
> > > > > > > > > - Drop redundant initialization
> > > > > > > > > - Wrap at 80 columns
> > > > > > > > > ---
> > > > > > > > > drivers/core/uclass.c | 32
> > > > > > > > > include/dm/uclass.h | 13 -
> > > > > > > > > test/dm/test-fdt.c| 20
> > > > > > > > > 3 files changed, 48 insertions(+), 17 deletions(-)
> > > > > > > >
> > > > > > > > Unfortunately this still fails one test. Try 'make qcheck' to
> > > > > > > > see it -
> > > > > > > > it is ethernet.
> > > > > > >
> > > > > > > I will look at that.
> > > > > > >
> > > > > > > > I actually think you should create new functions for this
> > > > > > > > feature,
> > > > > > > > e.g.uclass_first_device_ok(), since it makes it impossible to
> > > > > > > > see what
> > > > > > > > when wrong with a device in the middle.
> > > > > > > >
> > > > > > > > I have long had all this in my mind. One idea for a future
> > > > > > > > change is
> > > > > > > > to return the error, but set dev, so that the caller knows
> > > > > > > > there is a
> > > > > > > > device, which failed. When we are at the end, dev is set to
> > > > >
Re: [PATCH v3] dm: core: Do not stop uclass iteration on error
Hello,
On Sat, Sep 17, 2022 at 07:04:25PM +0200, Michal Suchánek wrote:
> Hello,
>
> On Sat, Sep 17, 2022 at 09:02:53AM -0600, Simon Glass wrote:
> > Hi Michal,
> >
> > On Wed, 31 Aug 2022 at 11:44, Simon Glass wrote:
> > >
> > > Hi Michal,
> > >
> > > On Wed, 31 Aug 2022 at 01:39, Michal Suchánek wrote:
> > > >
> > > > Hello,
> > > >
> > > > On Tue, Aug 30, 2022 at 09:15:12PM -0600, Simon Glass wrote:
> > > > > Hi Michal,
> > > > >
> > > > > On Tue, 30 Aug 2022 at 10:48, Michal Suchánek
> > > > > wrote:
> > > > > >
> > > > > > On Tue, Aug 30, 2022 at 09:56:52AM -0600, Simon Glass wrote:
> > > > > > > Hi Michal,
> > > > > > >
> > > > > > > On Tue, 30 Aug 2022 at 04:23, Michal Suchánek
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > On Sat, Aug 27, 2022 at 07:52:27PM -0600, Simon Glass wrote:
> > > > > > > > > Hi Michal,
> > > > > > > > >
> > > > > > > > > On Fri, 19 Aug 2022 at 14:23, Michal Suchanek
> > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > When probing a device fails NULL pointer is returned, and
> > > > > > > > > > other devices
> > > > > > > > > > cannot be iterated. Skip to next device on error instead.
> > > > > > > > > >
> > > > > > > > > > Fixes: 6494d708bf ("dm: Add base driver model support")
> > > > > > > > >
> > > > > > > > > I think you should drop this as you are doing a change of
> > > > > > > > > behaviour,
> > > > > > > > > not fixing a bug!
> > > > > > > >
> > > > > > > > You can hardly fix a bug without a change in behavior.
> > > > > > > >
> > > > > > > > These functions are used for iterating devices, and are not
> > > > > > > > iterating
> > > > > > > > devices. That's clearly a bug.
> > > > > > >
> > > > > > > If it were clear I would have changed this long ago. The new way
> > > > > > > you
> > > > > > > have this function ignores errors, so they cannot be reported.
> > > > > > >
> > > > > > > We should almost always report errors, which is why I think your
> > > > > > > methods should be named differently.
> > > > > > >
> > > > > > > >
> > > > > > > > > > Signed-off-by: Michal Suchanek
> > > > > > > > > > ---
> > > > > > > > > > v2: - Fix up tests
> > > > > > > > > > v3: - Fix up API doc
> > > > > > > > > > - Correctly forward error from uclass_get
> > > > > > > > > > - Do not return an error when last device fails to probe
> > > > > > > > > > - Drop redundant initialization
> > > > > > > > > > - Wrap at 80 columns
> > > > > > > > > > ---
> > > > > > > > > > drivers/core/uclass.c | 32
> > > > > > > > > > include/dm/uclass.h | 13 -
> > > > > > > > > > test/dm/test-fdt.c| 20
> > > > > > > > > > 3 files changed, 48 insertions(+), 17 deletions(-)
> > > > > > > > >
> > > > > > > > > Unfortunately this still fails one test. Try 'make qcheck' to
> > > > > > > > > see it -
> > > > > > > > > it is ethernet.
> > > > > > > >
> > > > > > > > I will look at that.
How do you debug test failures?
There is indeed a test that regresses.
However, when I run
ping 1.1.1.1
I get to see the printfs that I added to net_loop
when I run
ut dm dm_test_eth_act
u-boot crashes, and no printf output is seen, not even the print that
should report entering net_loop.
Given that the assert that is reported as failing is
test/dm/eth.c:133, dm_test_eth_act(): -ENODEV == net_loop(PING): Expected
0xffed (-19), got 0x0 (0)
it should run the net_loop to get that error.
It's nice that we have tests but if they cannot be debugged they are not
all that useful.
Thanks
Michal
Re: [PATCH v3] dm: core: Do not stop uclass iteration on error
On Sun, Sep 25, 2022 at 08:15:31AM -0600, Simon Glass wrote:
> Hi Michal,
>
> On Sat, 24 Sept 2022 at 14:10, Michal Suchánek wrote:
> >
> > Hello,
> >
> > On Sat, Sep 17, 2022 at 07:04:25PM +0200, Michal Suchánek wrote:
> > > Hello,
> > >
> > > On Sat, Sep 17, 2022 at 09:02:53AM -0600, Simon Glass wrote:
> > > > Hi Michal,
> > > >
> > > > On Wed, 31 Aug 2022 at 11:44, Simon Glass wrote:
> > > > >
> > > > > Hi Michal,
> > > > >
> > > > > On Wed, 31 Aug 2022 at 01:39, Michal Suchánek
> > > > > wrote:
> > > > > >
> > > > > > Hello,
> > > > > >
> > > > > > On Tue, Aug 30, 2022 at 09:15:12PM -0600, Simon Glass wrote:
> > > > > > > Hi Michal,
> > > > > > >
> > > > > > > On Tue, 30 Aug 2022 at 10:48, Michal Suchánek
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > On Tue, Aug 30, 2022 at 09:56:52AM -0600, Simon Glass wrote:
> > > > > > > > > Hi Michal,
> > > > > > > > >
> > > > > > > > > On Tue, 30 Aug 2022 at 04:23, Michal Suchánek
> > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > On Sat, Aug 27, 2022 at 07:52:27PM -0600, Simon Glass wrote:
> > > > > > > > > > > Hi Michal,
> > > > > > > > > > >
> > > > > > > > > > > On Fri, 19 Aug 2022 at 14:23, Michal Suchanek
> > > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > When probing a device fails NULL pointer is returned,
> > > > > > > > > > > > and other devices
> > > > > > > > > > > > cannot be iterated. Skip to next device on error
> > > > > > > > > > > > instead.
> > > > > > > > > > > >
> > > > > > > > > > > > Fixes: 6494d708bf ("dm: Add base driver model support")
> > > > > > > > > > >
> > > > > > > > > > > I think you should drop this as you are doing a change of
> > > > > > > > > > > behaviour,
> > > > > > > > > > > not fixing a bug!
> > > > > > > > > >
> > > > > > > > > > You can hardly fix a bug without a change in behavior.
> > > > > > > > > >
> > > > > > > > > > These functions are used for iterating devices, and are not
> > > > > > > > > > iterating
> > > > > > > > > > devices. That's clearly a bug.
> > > > > > > > >
> > > > > > > > > If it were clear I would have changed this long ago. The new
> > > > > > > > > way you
> > > > > > > > > have this function ignores errors, so they cannot be reported.
> > > > > > > > >
> > > > > > > > > We should almost always report errors, which is why I think
> > > > > > > > > your
> > > > > > > > > methods should be named differently.
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > > Signed-off-by: Michal Suchanek
> > > > > > > > > > > > ---
> > > > > > > > > > > > v2: - Fix up tests
> > > > > > > > > > > > v3: - Fix up API doc
> > > > > > > > > > > > - Correctly forward error from uclass_get
> > > > > > > > > > > > - Do not return an error when last device fails to
> > > > > > > > > > > > probe
> > > > > > > > > > > > - Drop redundant initialization
> > > > > > > > > > > > - Wrap at 80 columns
> > > > > > > > > > > > ---
> > > > > > > > > > > > drivers/core/uclass.c | 32
> > > > > > > > > > > >
> > > > > > > > > > > > include/dm/uclass.h | 13 -
> > > > > > > > > > > > test/dm/test-fdt.c| 20
> > > > > > > > > > > > 3 files changed, 48 insertions(+), 17 deletions(-)
> > > > > > > > > > >
> > > > > > > > > > > Unfortunately this still fails one test. Try 'make
> > > > > > > > > > > qcheck' to see it -
> > > > > > > > > > > it is ethernet.
> > > > > > > > > >
> > > > > > > > > > I will look at that.
> >
> > How do you debug test failures?
> >
> > There is indeed a test that regresses.
> >
> > However, when I run
> >
> > ping 1.1.1.1
> >
> > I get to see the printfs that I added to net_loop
> >
> > when I run
> >
> > ut dm dm_test_eth_act
> >
> > u-boot crashes, and no printf output is seen, not even the print that
> > should report entering net_loop.
> > Given that the assert that is reported as failing is
> > test/dm/eth.c:133, dm_test_eth_act(): -ENODEV == net_loop(PING): Expected
> > 0xffed (-19), got 0x0 (0)
> > it should run the net_loop to get that error.
> >
> > It's nice that we have tests but if they cannot be debugged they are not
> > all that useful.
>
> Why don't you try gdb?
That's certainly an option for sandbox.
However, I wonder what's the utility of hiding test output by default?
I can run non-test commands in the sandbox, and they produce output as
normal, and the tests don't.
I even found that this default is disabled by the automatedte tests.
Whent running qcheck the debug prints would be shown in the qcheck
output for the failing test.
So the question is who and when would want to hide the test output?
Thanks
Michal
Re: [RESEND 0/3] rockchip: Fix RAM training on RK3399 based platforms (Rock Pi 4)
On Wed, Sep 28, 2022 at 10:26:35AM +0100, Lee Jones wrote: > On Fri, 09 Sep 2022, Kever Yang wrote: > > > Hi Lee Jones, > > > > On 2022/9/8 15:44, Lee Jones wrote: > > > On Thu, 11 Aug 2022, Lee Jones wrote: > > > > > > > This set fixes several issues found on the Rock Pi 4. > > > > > > > > For full context, please see this initial bug report: > > > > > > > > "There appear to be a number of issues with the Rockchip rk3399 DDR > > > > RAM > > > >initialisation sequence in Mainline. Specifically, I'm seeing > > > >consistent failures on the Rock Pi 4+ during early boot. A typical > > > >failure looks something like this: > > > > U-Boot TPL 2022.07-rc3-5-g1b04a961c6 (May 25 2022 - 11:09:19) > > > > Channel 0: LPDDR4, 50MHz > > > > BW=32 Col=10 Bk=8 CS0 Row=16/15 CS=1 Die BW=16 Size=2048MB > > > > Channel 1: col error > > > > Cap error! > > > > 256B stride > > > > lpddr4_set_rate: change freq to 4 mhz 0, 1 > > > > lpddr4_set_rate: change freq to 8 mhz 1, 0 > > > > Trying to boot from BOOTROM > > > > Returning to boot ROM... > > > >Even when the system boots to a terminal, which happens very > > > >infrequently, the LPDDR4 RAM chip at Channel 1 can have conflicting > > > >discovery information printed during TPL. The following 3 lines were > > > >printed during successive reboots using the same SD card with no > > > >changes: > > > > # Boot 1: > > > > BW=32 Col=9 Bk=4 CS0 Row=16/15 CS=1 Die BW=16 Size=384MB > > > > # Boot 2: > > > > BW=32 Col=10 Bk=4 CS0 Row=16/15 CS=1 Die BW=16 Size=768MB > > > > # Boot 3: > > > > BW=32 Col=10 Bk=4 CS0 Row=15 CS=1 Die BW=16 Size=512MB > > > >The story changes when I build the idbloader.img image with > > > > Rockchip's > > > >TBL (?) binary blob [0]. With that built in, presumably in place of > > > >the upstream TBL, both RAM chips are successfully enumerated and boot > > > >succeeds with 100% success rate: > > > > tools/mkimage -n rk3399 -T rksd -d \ > > > >rk3399_ddr_933MHz_v1.25.bin:spl/u-boot-spl.bin idbloader.img > > > >Another thing that is very different between the 2 is the initial > > > >frequency the LPDDR4 chips are clocked at. Using the upstream TBL > > > >version, the default is 50Mhz, which seems very low. If using the > > > >Rockchip supplied binary blob file, this is increased to a > > > > respectable > > > >416MHz: > > > > # Mainline > > > > Channel 0: LPDDR4, 50MHz > > > > # Rockchip TBL blob > > > > Channel 0: LPDDR4,416MHz > > > >One thing I did try was to load in the 400Mhz configuration settings > > > >from drivers/ram/rockchip/sdram-rk3399-lpddr4-400.inc as the default > > > >initial values, instead of the 50MHz default taken from > > > >arch/arm/dts/rk3399-sdram-lpddr4-100.dtsi, but this failed in a > > > > number > > > >of ways: > > > > Setting clock: Freq: 400MHz (4) > > > > Calling SDRAM init: 2 Channels > > > > Starting SDRAM initialization... > > > >mr5:0 mr12:0 mr14:0 > > > >Training failed for rank 2, ch 0 (ret: -22) > > > >mr5:0 mr12:0 mr14:0 > > > >Training failed for rank 1, ch 0 (ret: -22) > > > >mr5:0 mr12:0 mr14:0 > > > >Training failed for rank 2, ch 1 (ret: -22) > > > >mr5:0 mr12:0 mr14:0 > > > >Training failed for rank 1, ch 1 (ret: -22) > > > >Rank for Channel 1 is 0x0 > > > >Rank for Channel 0 is 0x0 > > > >Rank for Channel 1 is 0x0 > > > > sdram_init: LPDDR4 - 400MHz failed! > > > > rk3399_dmc_init DRAM init failed -22 > > > >So my question is; does Rockchip, or anyone else for that matter, > > > > have > > > >any plans on updating Mainline U-Boot with the upgraded/working > > > > LPDDR4 > > > >initialisation sequence?" > > > > > > > > Lee Jones (3): > > > >ram: rk3399: Fix .set_rate_index() error handling > > > >ram: rk3399: Fix faulty frequency change reports > > > >ram: rk3399: Conduct memory training at 400MHz > > > > > > > > drivers/ram/rockchip/sdram_rk3399.c | 38 + > > > > 1 file changed, 23 insertions(+), 15 deletions(-) > > > Looks as though we have all the Reviews we need. > > > > > > Would someone be kind enough to merge these patches please? > > > > Yes, I will merge this patch set soon. > > Any luck with this Kever? Merged in 337e92e79c95ffb8c0c6e7b4023c955c50fca018 HTH Michal
Re: [PATCH v5 09/15] cmd: List all uclass devices regardless of probe error
Hello, On Thu, Sep 29, 2022 at 04:00:42AM -0600, Simon Glass wrote: > On Tue, 27 Sept 2022 at 15:38, Michal Suchanek wrote: > > > > There are a few commands that iterate uclass with > > uclass_first_device/uclass_next_device or the _err variant. > > > > Use the _check class iterator variant to get devices that fail to probe > > as well, and print the status. > > > > Signed-off-by: Michal Suchanek > > --- > > cmd/adc.c | 22 ++ > > cmd/demo.c | 16 ++-- > > cmd/gpio.c | 15 +++ > > cmd/pmic.c | 15 --- > > cmd/regulator.c | 13 +++-- > > 5 files changed, 46 insertions(+), 35 deletions(-) > > With the errno change dropped: Can you be please more sspecific about 'the errno change' and the problem with it? Thanks Michal > > Reviewed-by: Simon Glass
Re: [PATCH v5 04/15] bootstd: Fix listing boot devices
On Thu, Sep 29, 2022 at 04:00:32AM -0600, Simon Glass wrote: > Hi Michal, > > On Tue, 27 Sept 2022 at 15:38, Michal Suchanek wrote: > > > > bootdev_list() uses uclass_*_device_err() to iterate devices. > > However, the only value _err adds is returning an error when the device > > pointer is null, and that's checked anyway. > > > > Also there is some intent to report errors, and that's what > > uclass_*_device_check() is for, use it. > > > > Also print the symbolic error. > > Please drop that. We are talking about using %dE in a printf() string > to show that info (the error number as well as the error string if > available), so you could do that if you like. That sounds like a better solution. Thanks Michal > > But without errno_str support, this change just drops the error code. > > With that: > > Reviewed-by: Simon Glass > > Regards, > Simon
Re: [PATCH v4 04/21] dm: blk: Add probe in blk_first_device/blk_next_device
On Thu, Sep 29, 2022 at 04:00:26AM -0600, Simon Glass wrote:
> Hi Michal,
>
> On Sun, 25 Sept 2022 at 02:28, Michal Suchanek wrote:
> >
> > The description claims that the device is probed but it isn't.
> >
> > Add the device_probe() call.
> >
> > Also consolidate the iteration into one function.
> >
> > Fixes: 8a5cbc065d ("dm: blk: Use uclass_find_first/next_device() in
> > blk_first/next_device()")
> > Signed-off-by: Michal Suchanek
> > ---
> > drivers/block/blk-uclass.c | 46 ++
> > 1 file changed, 22 insertions(+), 24 deletions(-)
> >
> > diff --git a/drivers/block/blk-uclass.c b/drivers/block/blk-uclass.c
> > index 21c5209bb6..992f8ad3da 100644
> > --- a/drivers/block/blk-uclass.c
> > +++ b/drivers/block/blk-uclass.c
> > @@ -361,45 +361,43 @@ int blk_dselect_hwpart(struct blk_desc *desc, int
> > hwpart)
> > return blk_select_hwpart(desc->bdev, hwpart);
> > }
> >
> > -int blk_first_device(int if_type, struct udevice **devp)
> > +static int _blk_next_device(int if_type, struct udevice **devp)
> > {
> > struct blk_desc *desc;
> > - int ret;
> > + int ret = 0;
> > +
> > + for (; *devp; uclass_find_next_device(devp)) {
> > + desc = dev_get_uclass_plat(*devp);
> > + if (desc->if_type == if_type) {
> > + ret = device_probe(*devp);
> > + if (!ret)
> > + return 0;
> > + }
> > + }
> >
> > - ret = uclass_find_first_device(UCLASS_BLK, devp);
> > if (ret)
> > return ret;
> > - if (!*devp)
> > - return -ENODEV;
> > - do {
> > - desc = dev_get_uclass_plat(*devp);
> > - if (desc->if_type == if_type)
> > - return 0;
> > - ret = uclass_find_next_device(devp);
> > - if (ret)
> > - return ret;
> > - } while (*devp);
>
> This looks wrong since a media device may have other devices under it,
> e.g. UCLASS_BOOTDEV so I think you should keep the existing code and
> just call uclass_probe() at the end.
>
> You could add a test for this by checking that only the BLK device is probed.
The description says that it returns ready to use device, and that's not
possible when the device is only probed at the end when it is to be
returned.
There are some tests of this function but very few users so it may be OK
to change the semantic again to resemble the _check variant uclass
iterator and retorn broken devices but I don't think that was the intent
here with using uclass_first_device/uclass_next_device originally.
Also this change only makes a difference to the amount of devices probed
for callers that only call the blk_first_device and never move on to the
next. Callers that use the functions for iteration will move on to the
next device and probe it anyway.
Thanks
Michal
Re: [PATCH] power: pmic: rk8xx: Workaround pmic failure when probed before relocation
On Mon, Aug 08, 2022 at 01:26:23PM -0600, Simon Glass wrote:
> Hi Michal,
>
> On Sat, 6 Aug 2022 at 13:54, Michal Suchánek wrote:
> >
> > On Sat, Aug 06, 2022 at 12:21:29PM -0600, Simon Glass wrote:
> > > Hi Michal,
> > >
> > > On Fri, 5 Aug 2022 at 14:07, Michal Suchánek wrote:
> > > >
> > > > On Fri, Aug 05, 2022 at 10:48:26AM -0600, Simon Glass wrote:
> > > > > Hi Michal,
> > > > >
> > > > > On Fri, 5 Aug 2022 at 05:32, Michal Suchanek
> > > > > wrote:
> > > > > >
> > > > > > When the sysreset is added as child of the pmic the pmic is probed
> > > > > > before relocation. That probe fails, and subsequent attempts to
> > > > > > probe
> > > > > > after reloaction fail as well.
> > > > > >
> > > > > > As a workaround do not bind the sysreset before relocation.
> > > > > >
> > > > > > Signed-off-by: Michal Suchanek
> > > > > > ---
> > > > > > drivers/power/pmic/rk8xx.c | 2 +-
> > > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/drivers/power/pmic/rk8xx.c b/drivers/power/pmic/rk8xx.c
> > > > > > index a239a18674..d12263c4f2 100644
> > > > > > --- a/drivers/power/pmic/rk8xx.c
> > > > > > +++ b/drivers/power/pmic/rk8xx.c
> > > > > > @@ -131,7 +131,7 @@ static int rk8xx_read(struct udevice *dev, uint
> > > > > > reg, uint8_t *buff, int len)
> > > > > >
> > > > > > static int rk8xx_bind(struct udevice *dev)
> > > > > > {
> > > > > > - if (CONFIG_IS_ENABLED(SYSRESET)) {
> > > > > > + if (CONFIG_IS_ENABLED(SYSRESET) && (gd->flags &
> > > > > > GD_FLG_RELOC)) {
> > > > > > device_bind_driver(dev, "rk8xx_sysreset",
> > > > > >"rk8xx_sysreset", NULL);
> > > > > > }
> > > > > > --
> > > > > > 2.37.1
> > > > > >
> > > > >
> > > > > I think it is OK to avoid starting a device before relocation, or make
> > > > > that device do something different. I really don't like the binding
> > > > > being optional though...we have the 'u-boot,dm-pre-reloc' for that.
> > > >
> > > > So perhaps the flag should be dropped from rk8xx then.
> > > >
> > > > >
> > > > > But missing from your commit message is exactly what fails?
> > > >
> > > > The pmic is an i2c device, all i2c tranferss fail if initialized
> > > > pre-relocation. I supect it's the i2c bus that fails if initialized
> > > > before reloc - the regulatorss that share the i2c bus also report i2c
> > > > transfer failure.
> > >
> > > OK, I wonder why i2c fails? It works OK on the rockchip devices I'm
> > > familiar with, e.g. chromebooks.
> >
> > It worksss fine here as well - so long as it is not initialized before
> > relocation.
>
> I wonder if the clock driver is doing something different then, or has
> a limited number of clocks?
Looks like it is not the clocks.
There is something slightly fishy going on there with them:
In the broken case the i2c clock is not initialized before reloc
TICE: BL31: v2.6(debug):
NOTICE: BL31: Built : 14:50:40, Jul 1 2022
INFO:GICv3 with legacy support detected.
INFO:ARM GICv3 driver initialized in EL3
INFO:Maximum SPI INTID supported: 287
INFO:plat_rockchip_pmu_init(1624): pd status 3e
INFO:BL31: Initializing runtime services
INFO:BL31: cortex_a53: CPU workaround for 855873 was applied
WARNING: BL31: cortex_a53: CPU workaround for 1530924 was missing!
INFO:BL31: Preparing for EL3 exit to normal world
INFO:Entry point address = 0x20
INFO:SPSR = 0x3c9
rk8xx_bind
global flags 0 relocaddr 0
rk8xx_sysreset_bind
rk8xx_bind: 'pmic@1b' - found regulators subnode
rk3399_clk_get_rate: clk clock-controller@ff76 83
clock-controller@ff76 83: clock rate 2400
U-Boot 2022.07-00038-g61e11a8e9f-dirty (Aug 07 2022 - 19:53:20 +0200)
U-Boot PLL at ff75: fbdiv=112, refdiv=2, postdiv1=2, postdiv2=1,
vco=1344000 khz, output=672000 khz
i2c@ff3c: Got clock pmu-clock-controller@ff75 9
rockchip_i2c_probe: clk: pmu-clock-controller@ff75 9 rate 0 count 0 flags 0
rockchip_i2
Re: ethernet dt aliases implications in U-Boot and Linux
On Mon, Aug 08, 2022 at 03:57:55PM -0400, Sean Anderson wrote:
> Hi Tim,
>
> On 8/8/22 3:18 PM, Tim Harvey wrote:
> > Greetings,
> >
> > I'm trying to understand if there is any implication of 'ethernet'
> > aliases in Linux such as:
> > aliases {
> > ethernet0 = &eqos;
> > ethernet1 = &fec;
> > ethernet2 = &lan1;
> > ethernet3 = &lan2;
> > ethernet4 = &lan3;
> > ethernet5 = &lan4;
> > ethernet6 = &lan5;
> > };
> >
> > I know U-Boot boards that use device-tree will use these aliases to
> > name the devices in U-Boot such that the device with alias 'ethernet0'
> > becomes eth0 and alias 'ethernet1' becomes eth1 but for Linux it
> > appears that the naming of network devices that are embedded (ie SoC)
> > vs enumerated (ie pci/usb) are always based on device registration
> > order which for static drivers depends on Makefile linking order and
> > has nothing to do with device-tree.
> >
> > Is there currently any way to control network device naming in Linux
> > other than udev?
>
> You can also use systemd-networkd et al. (but that is the same kind of
> mechanism)
>
> > Does Linux use the ethernet aliases for anything at all?
>
> No :l
Maybe it's a great opportunity for porting biosdevname to DT based
platforms ;-)
Thanks
Michal
Re: ethernet dt aliases implications in U-Boot and Linux
On Mon, Aug 08, 2022 at 02:38:35PM -0700, Stephen Hemminger wrote:
> On Mon, 8 Aug 2022 23:09:45 +0200
> Michal Suchánek wrote:
>
> > On Mon, Aug 08, 2022 at 03:57:55PM -0400, Sean Anderson wrote:
> > > Hi Tim,
> > >
> > > On 8/8/22 3:18 PM, Tim Harvey wrote:
> > > > Greetings,
> > > >
> > > > I'm trying to understand if there is any implication of 'ethernet'
> > > > aliases in Linux such as:
> > > > aliases {
> > > > ethernet0 = &eqos;
> > > > ethernet1 = &fec;
> > > > ethernet2 = &lan1;
> > > > ethernet3 = &lan2;
> > > > ethernet4 = &lan3;
> > > > ethernet5 = &lan4;
> > > > ethernet6 = &lan5;
> > > > };
> > > >
> > > > I know U-Boot boards that use device-tree will use these aliases to
> > > > name the devices in U-Boot such that the device with alias 'ethernet0'
> > > > becomes eth0 and alias 'ethernet1' becomes eth1 but for Linux it
> > > > appears that the naming of network devices that are embedded (ie SoC)
> > > > vs enumerated (ie pci/usb) are always based on device registration
> > > > order which for static drivers depends on Makefile linking order and
> > > > has nothing to do with device-tree.
> > > >
> > > > Is there currently any way to control network device naming in Linux
> > > > other than udev?
> > >
> > > You can also use systemd-networkd et al. (but that is the same kind of
> > > mechanism)
> > >
> > > > Does Linux use the ethernet aliases for anything at all?
> > >
> > > No :l
> >
> > Maybe it's a great opportunity for porting biosdevname to DT based
> > platforms ;-)
>
> Sorry, biosdevname was wrong way to do things.
> Did you look at the internals, it was dumpster diving as root into BIOS.
When it's BIOS what defines the names then you have to read them from
the BIOS. Recently it was updated to use some sysfs file or whatver.
It's not like you would use any of that code with DT, anyway.
> Systemd-networkd does things in much more supportable manner using existing
> sysfs API's.
Which is a dumpster of systemd code, no thanks.
I want my device naming independent of the init system, especially if
it's systemd.
Thanks
Michal
Re: ethernet dt aliases implications in U-Boot and Linux
On Wed, Aug 10, 2022 at 03:11:48AM +0200, Andrew Lunn wrote:
> > Is something like the following really that crazy of an idea?
> > diff --git a/net/core/dev.c b/net/core/dev.c
> > index e0878a500aa9..a679c74a63c6 100644
> > --- a/net/core/dev.c
> > +++ b/net/core/dev.c
> > @@ -1151,6 +1151,15 @@ static int dev_alloc_name_ns(struct net *net,
> > int ret;
> >
> > BUG_ON(!net);
> > +#ifdef CONFIG_OF
> > + if (dev->dev.parent && dev->dev.parent->of_node) {
> > + const char *name =
> > of_get_property(dev->dev.parent->of_node, "label", NULL);
> > + if (name) {
> > + strlcpy(dev->name, name, IFNAMSIZ);
> > + return 0;
> > + }
> > + }
> > +#endif
> > ret = __dev_alloc_name(net, name, buf);
> > if (ret >= 0)
> > strlcpy(dev->name, buf, IFNAMSIZ);
> >
> > I still like using the index from aliases/ethernet* instead as there
> > is a precedence for that in other Linux drivers as well as U-Boot
>
> I guess you are new to the netdev list :-)
>
> This is one of those FAQ sort of things, discussed every
> year. Anything like this is always NACKed. I don't see why this time
> should be any different.
>
> DSA is somewhat special because it is very old. It comes from before
> the times of DT. Its DT binding was proposed relatively earl in DT
> times, and would be rejected in modern days. But the rules of ABI mean
> the label property will be valid forever. But i very much doubt it
> will spread to interfaces in general.
And if this is a FAQ maybe you can point to a summary (perhaps in
previous mail discusssion) that explains how to provide stable interface
names for Ethernet devices on a DT based platform?
On x86 there is a name derived from the device location in the bus
topology which may be somewhat stable but it is not clear that it
cannot change, and there is an optional BIOS provided table that can
asssign meaningful names to the interfaces.
What are the equivalents for DT?
Thanks
Michal
Re: ethernet dt aliases implications in U-Boot and Linux
On Wed, Aug 10, 2022 at 05:17:56PM +0200, Andrew Lunn wrote: > > > I guess you are new to the netdev list :-) > > > > > > This is one of those FAQ sort of things, discussed every > > > year. Anything like this is always NACKed. I don't see why this time > > > should be any different. > > > > > > DSA is somewhat special because it is very old. It comes from before > > > the times of DT. Its DT binding was proposed relatively earl in DT > > > times, and would be rejected in modern days. But the rules of ABI mean > > > the label property will be valid forever. But i very much doubt it > > > will spread to interfaces in general. > > > > And if this is a FAQ maybe you can point to a summary (perhaps in > > previous mail discusssion) that explains how to provide stable interface > > names for Ethernet devices on a DT based platform? > > As far so the kernel is concerned, interface names are unstable. They > have never been truly stable, but they have got more unstable in the > past decade with multiple busses being probed in parallel, which did > not happen before so much. > > > On x86 there is a name derived from the device location in the bus > > topology > > This is nothing to do with x86. That is userspace, e.g. systemd, > renaming the interfaces. This applies for any architecture for which > systemd runs on. > > > which may be somewhat stable but it is not clear that it > > cannot change, and there is an optional BIOS provided table that can > > asssign meaningful names to the interfaces. > > I doubt the kernel is looking at ACPI tables. It is user space which > does that. > > The kernel provides udev with a bunch of information about the > interface, its bus location, MAC address, etc. Userspace can then > decide what it wants to call it, and what its alternative names are, > etc. > > Also, this is not just a network interface name problem. Any device > with a number/letter in it is unstable. I2C bus devices: i2c0, > i2c1... SPI bus deviceS: spi0, spi1..., Thees do have numbered aliases in the DT. I don't know if the kernel uses them for anything. > Block devices, sda, sdb, sdc, These too, at least mmc. Thanks Michal
Re: [PATCH 3/3] ram: rk3399: Conduct memory training at 400MHz
On Thu, Aug 11, 2022 at 08:58:48AM +0100, Lee Jones wrote:
> Currently the default initialisation frequency is 50MHz. Although
> this does appear to be suitable for some LPDDR4 RAM chips, training at
> this low frequency has been seen to cause Column errors, leading to
> Capacity check errors on others.
>
> Here we force RAM initialisation to happen at 400MHz before ramping up
> to the final value running value of 800MHz after everything has been
> successfully configured.
>
> Link: https://lore.kernel.org/u-boot/yo4v3juehxtov...@google.com/
> Suggested-by: YouMin Chen
> Signed-off-by: Lee Jones
> Tested-by: Xavier Drudis Ferran
Also does not cause any regression on a Pinebook Pro
Tested-by: Michal Suchánek
Thanks
Michal
> Reviewed-by: Kever Yang
> ---
> drivers/ram/rockchip/sdram_rk3399.c | 36 +
> 1 file changed, 21 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/ram/rockchip/sdram_rk3399.c
> b/drivers/ram/rockchip/sdram_rk3399.c
> index 34d6c93f95..b05c5925d5 100644
> --- a/drivers/ram/rockchip/sdram_rk3399.c
> +++ b/drivers/ram/rockchip/sdram_rk3399.c
> @@ -85,7 +85,7 @@ struct sdram_rk3399_ops {
> int (*data_training_first)(struct dram_info *dram, u32 channel, u8 rank,
> struct rk3399_sdram_params *sdram);
> int (*set_rate_index)(struct dram_info *dram,
> - struct rk3399_sdram_params *params);
> + struct rk3399_sdram_params *params, u32 ctl_fn);
> void (*modify_param)(const struct chan_info *chan,
>struct rk3399_sdram_params *params);
> struct rk3399_sdram_params *
> @@ -1644,7 +1644,8 @@ static int data_training_first(struct dram_info *dram,
> u32 channel, u8 rank,
> }
>
> static int switch_to_phy_index1(struct dram_info *dram,
> - struct rk3399_sdram_params *params)
> + struct rk3399_sdram_params *params,
> + u32 unused)
> {
> u32 channel;
> u32 *denali_phy;
> @@ -2539,26 +2540,25 @@ static int lpddr4_set_ctl(struct dram_info *dram,
> }
>
> static int lpddr4_set_rate(struct dram_info *dram,
> -struct rk3399_sdram_params *params)
> + struct rk3399_sdram_params *params,
> + u32 ctl_fn)
> {
> - u32 ctl_fn;
> u32 phy_fn;
>
> - for (ctl_fn = 0; ctl_fn < 2; ctl_fn++) {
> - phy_fn = lpddr4_get_phy_fn(params, ctl_fn);
> + phy_fn = lpddr4_get_phy_fn(params, ctl_fn);
>
> - lpddr4_set_phy(dram, params, phy_fn, &dfs_cfgs_lpddr4[ctl_fn]);
> - lpddr4_set_ctl(dram, params, ctl_fn,
> -dfs_cfgs_lpddr4[ctl_fn].base.ddr_freq);
> + lpddr4_set_phy(dram, params, phy_fn, &dfs_cfgs_lpddr4[ctl_fn]);
> + lpddr4_set_ctl(dram, params, ctl_fn,
> +dfs_cfgs_lpddr4[ctl_fn].base.ddr_freq);
>
> - if (IS_ENABLED(CONFIG_RAM_ROCKCHIP_DEBUG))
> - printf("%s: change freq to %dMHz %d, %d\n", __func__,
> -dfs_cfgs_lpddr4[ctl_fn].base.ddr_freq / MHz,
> -ctl_fn, phy_fn);
> - }
> + if (IS_ENABLED(CONFIG_RAM_ROCKCHIP_DEBUG))
> + printf("%s: change freq to %dMHz %d, %d\n", __func__,
> +dfs_cfgs_lpddr4[ctl_fn].base.ddr_freq / MHz,
> +ctl_fn, phy_fn);
>
> return 0;
> }
> +
> #endif /* CONFIG_RAM_RK3399_LPDDR4 */
>
> /* CS0,n=1
> @@ -2955,6 +2955,12 @@ static int sdram_init(struct dram_info *dram,
> params->ch[ch].cap_info.rank = rank;
> }
>
> +#if defined(CONFIG_RAM_RK3399_LPDDR4)
> + /* LPDDR4 needs to be trained at 400MHz */
> + lpddr4_set_rate(dram, params, 0);
> + params->base.ddr_freq = dfs_cfgs_lpddr4[0].base.ddr_freq / MHz;
> +#endif
> +
> params->base.num_channels = 0;
> for (channel = 0; channel < 2; channel++) {
> const struct chan_info *chan = &dram->chan[channel];
> @@ -3005,7 +3011,7 @@ static int sdram_init(struct dram_info *dram,
> params->base.stride = calculate_stride(params);
> dram_all_config(dram, params);
>
> - ret = dram->ops->set_rate_index(dram, params);
> + ret = dram->ops->set_rate_index(dram, params, 1);
> if (ret)
> return ret;
>
> --
> 2.37.1.559.g78731f0fdb-goog
>
Re: [PATCH v2] dm: core: Do not stop uclass iteration on error.
On Thu, Aug 18, 2022 at 11:49:53AM -0600, Simon Glass wrote:
> Hi Michal,
>
> On Wed, 17 Aug 2022 at 02:28, Michal Suchanek wrote:
> >
> > When probing a device fails NULL pointer is returned, and other devices
> > cannot be iterated. Skip to next device on error instead.
> >
> > Fixes: 6494d708bf ("dm: Add base driver model support")
> > Signed-off-by: Michal Suchanek
> > ---
> > v2: Fix up tests
> >
> > Note: there is seemingly bogus repeated device_remove(parent,
> DM_REMOVE_NORMAL);
> > but I have no idea what the intent was, and fixing that is out of the
> > scope of this patch anyway.
>
> This is to remove child devices that have been probed, so that we get back
> to the original state.
Thanks, it makes sense now.
> >
> > drivers/core/uclass.c | 30 +-
> > test/dm/test-fdt.c| 20
> > 2 files changed, 37 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/core/uclass.c b/drivers/core/uclass.c
> > index 08d9ed82de..ccf7d59141 100644
> > --- a/drivers/core/uclass.c
> > +++ b/drivers/core/uclass.c
> > @@ -574,16 +574,31 @@ int uclass_get_device_by_phandle(enum uclass_id id,
> struct udevice *parent,
> > }
> > #endif
> >
> > +/* Starting from the given device return first device in the uclass that
> probes successfully */
> > +static int __uclass_next_device(struct udevice *dev, int ret, struct
> udevice **devp)
>
> Can you avoid __ as this is reserved for compiler. Perhaps use a single
> underscore?
>
> Please check 80cols
whatever
> > +{
> > + if (!dev) {
> > + *devp = dev;
> > + return 0;
> > + }
>
> Is this for people that call next after they shouldn't?
This is for the case if there is nothing.
> > + while ((ret = uclass_get_device_tail(dev, ret, devp))) {
> > + ret = uclass_find_next_device(&dev);
> > + if (!dev) {
> > + *devp = dev;
> > + return 0;
> > + }
> > + }
> > +
> > + return ret;
> > +}
> > +
> > int uclass_first_device(enum uclass_id id, struct udevice **devp)
> > {
> > - struct udevice *dev;
> > + struct udevice *dev = NULL;
>
> Can you drop the NULL assignment? uclass_find_first_device() sets dev to
> NULL anyway, as a first step.
>
> > int ret;
> >
> > - *devp = NULL;
>
> Is this safe to remove? If there is nothing, then
it's the same as uclass_next_device() on the last device.
>
> > ret = uclass_find_first_device(id, &dev);
> > - if (!dev)
> > - return 0;
> > - return uclass_get_device_tail(dev, ret, devp);
> > + return __uclass_next_device(dev, ret, devp);
> > }
> >
> > int uclass_first_device_err(enum uclass_id id, struct udevice **devp)
> > @@ -604,11 +619,8 @@ int uclass_next_device(struct udevice **devp)
> > struct udevice *dev = *devp;
> > int ret;
> >
> > - *devp = NULL;
> > ret = uclass_find_next_device(&dev);
> > - if (!dev)
> > - return 0;
> > - return uclass_get_device_tail(dev, ret, devp);
> > + return __uclass_next_device(dev, ret, devp);
> > }
>
> This is a major change in behaviour, so please do update the API docs at
> dm/uclass.h
Yes, those need updating as well.
Thanks
Michal
Re: [PATCH] doc: dm: clarify activation.
Hello, On Sat, Aug 20, 2022 at 08:27:05AM +0200, Heinrich Schuchardt wrote: > On 8/4/22 22:30, Simon Glass wrote: > > Hi Michal, > > > > On Thu, 4 Aug 2022 at 13:42, Michal Suchánek wrote: > > > > > > On Thu, Aug 04, 2022 at 01:22:53PM -0600, Simon Glass wrote: > > > > Hi Michal, > > > > > > > > On Thu, 4 Aug 2022 at 11:58, Michal Suchanek wrote: > > > > > > > > > > Explain when devices should get activated. > > > > > > > > > > Signed-off-by: Michal Suchanek > > > > > --- > > > > > doc/develop/driver-model/design.rst | 22 -- > > > > > 1 file changed, 20 insertions(+), 2 deletions(-) > > > > > > > > Reviewed-by: Simon Glass > > > > > > > > Much appreciated! > > > > > > > > one note below > > > > > > > > > > > > > > diff --git a/doc/develop/driver-model/design.rst > > > > > b/doc/develop/driver-model/design.rst > > > > > index 5f33f9fbb3..c925d21b24 100644 > > > > > --- a/doc/develop/driver-model/design.rst > > > > > +++ b/doc/develop/driver-model/design.rst > > > > > @@ -794,8 +794,26 @@ fall afoul of this rule. > > > > > Activation/probe > > > > > > > > > > > > > > > -When a device needs to be used, U-Boot activates it, by first > > > > > reading ofdata > > > > > -as above and then following these steps (see device_probe()): > > > > > +To save resources devices in U-Boot are probed lazily. U-Boot is a > > > > > bootloader, > > > > > +not an operating system. Many devices are never used during an > > > > > U-Boot run, and > > > > > +probing them takes time, requires memory, may add delays to the main > > > > > loop, etc. > > > > > + > > > > > +The device should be probed by the uclass code. Different uclasses > > > > > are > > When merging I will put the following here: > > The device should be probed by the uclass code or generic device code > (e.g. device_find_global_by_ofnode()). Uclasses differ but two common > use cases can be seen: I wanted to look at this direct device lookup, and send a v2 when I am done with it. I am currently trying to figure out how (if at all) the pins and clocks required by i2c devices are activated, and I suppose this direct lookup would be related. Noneteless, if you can fix up the patch right away that's great. Thanks Michal > > Best regards > > Heinrich > > > > > > > > > or the device code (e.g. device_get_child()) > > > > > > Can you elaborate a bit more, please? > > > > I mean that we can use 'device' code to probe, as well as the 'uclass' > > code. The function I cite is an example of that, but actually a better > > one is device_find_global_by_ofnode() > > > > > > > > This change is the reasult of some previous discussion about the device > > > activation with Marek. > > > > > > The device activation is really difficult to understand for people who > > > did not participate in designing the DM, and is probably quite specific > > > to U-Boot. > > > > OK, well good to have it. I wish more people would do what you have > > done here, i.e. go back and update the docs to clarify things that you > > found confusing / inadequate. > > > > > > > > > > > > > BTW probing a child probes all its parents automatically (that is said > > > > elsewhere I think). > > > > > > Yes, right below this part. > > > > > > Thanks > > > > > > Michal > > > > OK > > > > Regards, > > Simon > > > > > > > > > > > > > > > > +different but two common use cases can be seen: > > > > > + > > > > > + 1. The uclass is asked to look up a specific device, such as SPI > > > > > bus 0, > > > > > + first chip select - in this case the returned device should be > > > > > + activated. > > > > > + > > > > > + 2. The uclass is asked to perform a specific function on any > > > > > device that > > > > > + supports it, eg. reset the board using any sysreset that can be > > > > > found - > > > > > + for this case the core uclass code provides iterators that > > > > > activate > > > > > + each device before returning it, and the uclass typically > > > > > implements a > > > > > + walk function that iterates over all devices of the uclass and > > > > > tries > > > > > + to perform the requested function on each in turn until succesful. > > > > > + > > > > > +To activate a device U-Boot first reads ofdata as above and then > > > > > follows these > > > > > +steps (see device_probe()): > > > > > > > > > > 1. All parent devices are probed. It is not possible to activate > > > > > a device > > > > > unless its predecessors (all the way up to the root device) are > > > > > activated. > > > > > -- > > > > > 2.37.1 > > > > > > > > > > > > > Regards, > > > > Simon >
Re: [PATCH 1/2] patman: do not hardcode coverage tool
On Tue, Aug 30, 2022 at 12:01:55PM +0200, Quentin Schulz wrote:
> Hi Michal,
>
> On 8/25/22 08:49, Michal Suchanek wrote:
> > The coverage tool name varies across distributions.
> >
> > Add COVERAGE variable to specify the tool name.
> >
> > Also there is one place where prefix is prepended to the tool path,
> > remove the prefix.
> >
> > Signed-off-by: Michal Suchanek
> > ---
> > doc/develop/testing.rst | 3 +++
> > tools/patman/test_util.py | 18 ++
> > 2 files changed, 13 insertions(+), 8 deletions(-)
> >
> > diff --git a/doc/develop/testing.rst b/doc/develop/testing.rst
> > index 1abe4d7f0f..054fbfc814 100644
> > --- a/doc/develop/testing.rst
> > +++ b/doc/develop/testing.rst
> > @@ -17,6 +17,9 @@ To run most tests on sandbox, type this::
> > in the U-Boot directory. Note that only the pytest suite is run using this
> > command.
> > +Note: external tool `python3-coverage` is used by tests. The environment
> > +variable `COVERAGE` can be set to alternative name or location of this
> > tool.
> > +
> > Some tests take ages to run and are marked with @pytest.mark.slow. To run
> > just
> > the quick ones, type this::
> > diff --git a/tools/patman/test_util.py b/tools/patman/test_util.py
> > index 0f6d1aa902..e11806b626 100644
> > --- a/tools/patman/test_util.py
> > +++ b/tools/patman/test_util.py
> > @@ -15,6 +15,8 @@ from patman import command
> > from io import StringIO
> > +coverage = os.environ.get('COVERAGE', 'python3-coverage')
> > +
> > buffer_outputs = True
> > use_concurrent = True
> > try:
> > @@ -58,11 +60,11 @@ def run_test_coverage(prog, filter_fname, exclude_list,
> > build_dir, required=None
> > prefix = ''
> > if build_dir:
> > prefix = 'PYTHONPATH=$PYTHONPATH:%s/sandbox_spl/tools ' %
> > build_dir
> > -cmd = ('%spython3-coverage run '
> > - '--omit "%s" %s %s %s -P1' % (prefix, ','.join(glob_list),
> > +cmd = ('%s run '
> > + '--omit "%s" %s %s %s -P1' % (coverage, ','.join(glob_list),
> >prog, extra_args or '',
> > test_cmd))
>
> What about using
> python3 -m coverage run
> instead?
> This way we wouldn't rely on the binary name the host distribution chooses
> (python3-coverage for Ubuntu, coverage for Fedora).
>
> I'm not sure there is a need to give the user the ability to override this
> value since I expect only coverage.py is supported at the moment?
Then you run into the problems that you do not have coverage on
python3.4 but only python3.6 or whatever is the relevant version for
your distribution ATM.
In other words the only general solution is to specify the tool AFAICT.
Thanks
Michal
Re: [PATCH 2/2] tests: Do not hardcode sudo tool
On Thu, Aug 25, 2022 at 09:01:08AM -0600, Simon Glass wrote: > Hi Michal, > > On Wed, 24 Aug 2022 at 23:51, Michal Suchanek wrote: > > > > In some situations it may be needed to pass parameters to sudo or to use > > a different tool to gain root access. Add SUDO variable to specify the > > sudo tool. > > > > Signed-off-by: Michal Suchanek > > --- > > doc/develop/testing.rst | 5 +++-- > > test/fs/fat-noncontig-test.sh | 9 + > > test/fs/fs-test.sh| 26 ++ > > test/py/tests/test_fs/conftest.py | 8 +--- > > test/py/tests/test_ut.py | 14 -- > > 5 files changed, 35 insertions(+), 27 deletions(-) > > This is missing a change log and should have 'Series-version: 2' if > you are using patman. Hello, sorry for the confusion. This is v2 for https://lists.denx.de/pipermail/u-boot/2022-August/492636.html https://lists.denx.de/pipermail/u-boot/2022-August/492637.html and adds the documentation changes. With that the patches are no longer independent and need to be applied in order. I do not use patman, the coverage results (or errors about missing coverage tool) are displayed during test runs. Thanks Michal
Re: [PATCH v3] dm: core: Do not stop uclass iteration on error
On Sat, Aug 27, 2022 at 07:52:27PM -0600, Simon Glass wrote:
> Hi Michal,
>
> On Fri, 19 Aug 2022 at 14:23, Michal Suchanek wrote:
> >
> > When probing a device fails NULL pointer is returned, and other devices
> > cannot be iterated. Skip to next device on error instead.
> >
> > Fixes: 6494d708bf ("dm: Add base driver model support")
>
> I think you should drop this as you are doing a change of behaviour,
> not fixing a bug!
You can hardly fix a bug without a change in behavior.
These functions are used for iterating devices, and are not iterating
devices. That's clearly a bug.
> > Signed-off-by: Michal Suchanek
> > ---
> > v2: - Fix up tests
> > v3: - Fix up API doc
> > - Correctly forward error from uclass_get
> > - Do not return an error when last device fails to probe
> > - Drop redundant initialization
> > - Wrap at 80 columns
> > ---
> > drivers/core/uclass.c | 32
> > include/dm/uclass.h | 13 -
> > test/dm/test-fdt.c| 20
> > 3 files changed, 48 insertions(+), 17 deletions(-)
>
> Unfortunately this still fails one test. Try 'make qcheck' to see it -
> it is ethernet.
I will look at that.
> I actually think you should create new functions for this feature,
> e.g.uclass_first_device_ok(), since it makes it impossible to see what
> when wrong with a device in the middle.
>
> I have long had all this in my mind. One idea for a future change is
> to return the error, but set dev, so that the caller knows there is a
> device, which failed. When we are at the end, dev is set to NULL.
We already have uclass_first_device_check() and
uclass_next_device_check() to iterate all devices, including broken
ones, and getting the errors as well.
That's for the case you want all the details, and these are for the case
you just want to get devices and don't care about the details.
That's AFAICT as much as this iteration interface can provide, and we
have both cases covered.
Thanks
Michal
Re: [PATCH v3] dm: core: Do not stop uclass iteration on error
On Tue, Aug 30, 2022 at 09:56:52AM -0600, Simon Glass wrote:
> Hi Michal,
>
> On Tue, 30 Aug 2022 at 04:23, Michal Suchánek wrote:
> >
> > On Sat, Aug 27, 2022 at 07:52:27PM -0600, Simon Glass wrote:
> > > Hi Michal,
> > >
> > > On Fri, 19 Aug 2022 at 14:23, Michal Suchanek wrote:
> > > >
> > > > When probing a device fails NULL pointer is returned, and other devices
> > > > cannot be iterated. Skip to next device on error instead.
> > > >
> > > > Fixes: 6494d708bf ("dm: Add base driver model support")
> > >
> > > I think you should drop this as you are doing a change of behaviour,
> > > not fixing a bug!
> >
> > You can hardly fix a bug without a change in behavior.
> >
> > These functions are used for iterating devices, and are not iterating
> > devices. That's clearly a bug.
>
> If it were clear I would have changed this long ago. The new way you
> have this function ignores errors, so they cannot be reported.
>
> We should almost always report errors, which is why I think your
> methods should be named differently.
>
> >
> > > > Signed-off-by: Michal Suchanek
> > > > ---
> > > > v2: - Fix up tests
> > > > v3: - Fix up API doc
> > > > - Correctly forward error from uclass_get
> > > > - Do not return an error when last device fails to probe
> > > > - Drop redundant initialization
> > > > - Wrap at 80 columns
> > > > ---
> > > > drivers/core/uclass.c | 32
> > > > include/dm/uclass.h | 13 -
> > > > test/dm/test-fdt.c| 20
> > > > 3 files changed, 48 insertions(+), 17 deletions(-)
> > >
> > > Unfortunately this still fails one test. Try 'make qcheck' to see it -
> > > it is ethernet.
> >
> > I will look at that.
> >
> > > I actually think you should create new functions for this feature,
> > > e.g.uclass_first_device_ok(), since it makes it impossible to see what
> > > when wrong with a device in the middle.
> > >
> > > I have long had all this in my mind. One idea for a future change is
> > > to return the error, but set dev, so that the caller knows there is a
> > > device, which failed. When we are at the end, dev is set to NULL.
> >
> > We already have uclass_first_device_check() and
> > uclass_next_device_check() to iterate all devices, including broken
> > ones, and getting the errors as well.
> >
> > That's for the case you want all the details, and these are for the case
> > you just want to get devices and don't care about the details.
> >
> > That's AFAICT as much as this iteration interface can provide, and we
> > have both cases covered.
>
> I see three cases:
> - want to see the next device, returning the error if it cannot be
> probed - uclass_first_device()
And the point of this is what exactly?
The device order in the uclass is not well defined - at any time a new
device which will become the first can be added, fail probe, and block
what was assumed a loop iterating the uclass from returning any devices
at all. That's exactly what happened with the new sysreset.
What is exactly the point of returning the error and not the pointer to
the next device?
The only point of these simplified iterators is that the caller can
check only one value (device pointer) and then not check the error
because they don't care. If they do cate uclass_first_device_check()
provides all the details available.
> - want to get the next device that can successfully probe - your new functions
> - want to see each device, along with any errors - uclass_first_device_check()
Thanks
Michal
Re: [PATCH v3] dm: core: Do not stop uclass iteration on error
Hello,
On Tue, Aug 30, 2022 at 09:15:12PM -0600, Simon Glass wrote:
> Hi Michal,
>
> On Tue, 30 Aug 2022 at 10:48, Michal Suchánek wrote:
> >
> > On Tue, Aug 30, 2022 at 09:56:52AM -0600, Simon Glass wrote:
> > > Hi Michal,
> > >
> > > On Tue, 30 Aug 2022 at 04:23, Michal Suchánek wrote:
> > > >
> > > > On Sat, Aug 27, 2022 at 07:52:27PM -0600, Simon Glass wrote:
> > > > > Hi Michal,
> > > > >
> > > > > On Fri, 19 Aug 2022 at 14:23, Michal Suchanek
> > > > > wrote:
> > > > > >
> > > > > > When probing a device fails NULL pointer is returned, and other
> > > > > > devices
> > > > > > cannot be iterated. Skip to next device on error instead.
> > > > > >
> > > > > > Fixes: 6494d708bf ("dm: Add base driver model support")
> > > > >
> > > > > I think you should drop this as you are doing a change of behaviour,
> > > > > not fixing a bug!
> > > >
> > > > You can hardly fix a bug without a change in behavior.
> > > >
> > > > These functions are used for iterating devices, and are not iterating
> > > > devices. That's clearly a bug.
> > >
> > > If it were clear I would have changed this long ago. The new way you
> > > have this function ignores errors, so they cannot be reported.
> > >
> > > We should almost always report errors, which is why I think your
> > > methods should be named differently.
> > >
> > > >
> > > > > > Signed-off-by: Michal Suchanek
> > > > > > ---
> > > > > > v2: - Fix up tests
> > > > > > v3: - Fix up API doc
> > > > > > - Correctly forward error from uclass_get
> > > > > > - Do not return an error when last device fails to probe
> > > > > > - Drop redundant initialization
> > > > > > - Wrap at 80 columns
> > > > > > ---
> > > > > > drivers/core/uclass.c | 32
> > > > > > include/dm/uclass.h | 13 -
> > > > > > test/dm/test-fdt.c| 20
> > > > > > 3 files changed, 48 insertions(+), 17 deletions(-)
> > > > >
> > > > > Unfortunately this still fails one test. Try 'make qcheck' to see it -
> > > > > it is ethernet.
> > > >
> > > > I will look at that.
> > > >
> > > > > I actually think you should create new functions for this feature,
> > > > > e.g.uclass_first_device_ok(), since it makes it impossible to see what
> > > > > when wrong with a device in the middle.
> > > > >
> > > > > I have long had all this in my mind. One idea for a future change is
> > > > > to return the error, but set dev, so that the caller knows there is a
> > > > > device, which failed. When we are at the end, dev is set to NULL.
> > > >
> > > > We already have uclass_first_device_check() and
> > > > uclass_next_device_check() to iterate all devices, including broken
> > > > ones, and getting the errors as well.
> > > >
> > > > That's for the case you want all the details, and these are for the case
> > > > you just want to get devices and don't care about the details.
> > > >
> > > > That's AFAICT as much as this iteration interface can provide, and we
> > > > have both cases covered.
> > >
> > > I see three cases:
> > > - want to see the next device, returning the error if it cannot be
> > > probed - uclass_first_device()
> >
> > And the point of this is what exactly?
>
> Please can you adjust your tone, It seems too aggressive for this
> mailing list. Thank you.
>
> >
> > The device order in the uclass is not well defined - at any time a new
> > device which will become the first can be added, fail probe, and block
> > what was assumed a loop iterating the uclass from returning any devices
> > at all. That's exactly what happened with the new sysreset.
>
> The order only changes if the device is unbound and rebound. Otherwise
> the order set by the device tree is used.
So the order is defined by device tree. That does not make it
well-defined from the point of view of any kind of code.
The point of device tree is that it can be replace
Re: [PATCH 1/2] patman: do not hardcode coverage tool
Hello,
On Wed, Aug 31, 2022 at 12:08:32PM +0200, Quentin Schulz wrote:
> Hi Michal,
>
> On 8/30/22 12:11, Michal Suchánek wrote:
> > On Tue, Aug 30, 2022 at 12:01:55PM +0200, Quentin Schulz wrote:
> > > Hi Michal,
> > >
> > > On 8/25/22 08:49, Michal Suchanek wrote:
> > > > The coverage tool name varies across distributions.
> > > >
> > > > Add COVERAGE variable to specify the tool name.
> > > >
> > > > Also there is one place where prefix is prepended to the tool path,
> > > > remove the prefix.
> > > >
> > > > Signed-off-by: Michal Suchanek
> > > > ---
> > > >doc/develop/testing.rst | 3 +++
> > > >tools/patman/test_util.py | 18 ++
> > > >2 files changed, 13 insertions(+), 8 deletions(-)
> > > >
> > > > diff --git a/doc/develop/testing.rst b/doc/develop/testing.rst
> > > > index 1abe4d7f0f..054fbfc814 100644
> > > > --- a/doc/develop/testing.rst
> > > > +++ b/doc/develop/testing.rst
> > > > @@ -17,6 +17,9 @@ To run most tests on sandbox, type this::
> > > >in the U-Boot directory. Note that only the pytest suite is run
> > > > using this
> > > >command.
> > > > +Note: external tool `python3-coverage` is used by tests. The
> > > > environment
> > > > +variable `COVERAGE` can be set to alternative name or location of this
> > > > tool.
> > > > +
> > > >Some tests take ages to run and are marked with @pytest.mark.slow.
> > > > To run just
> > > >the quick ones, type this::
> > > > diff --git a/tools/patman/test_util.py b/tools/patman/test_util.py
> > > > index 0f6d1aa902..e11806b626 100644
> > > > --- a/tools/patman/test_util.py
> > > > +++ b/tools/patman/test_util.py
> > > > @@ -15,6 +15,8 @@ from patman import command
> > > >from io import StringIO
> > > > +coverage = os.environ.get('COVERAGE', 'python3-coverage')
> > > > +
> > > >buffer_outputs = True
> > > >use_concurrent = True
> > > >try:
> > > > @@ -58,11 +60,11 @@ def run_test_coverage(prog, filter_fname,
> > > > exclude_list, build_dir, required=None
> > > >prefix = ''
> > > >if build_dir:
> > > >prefix = 'PYTHONPATH=$PYTHONPATH:%s/sandbox_spl/tools ' %
> > > > build_dir
> > > > -cmd = ('%spython3-coverage run '
> > > > - '--omit "%s" %s %s %s -P1' % (prefix, ','.join(glob_list),
> > > > +cmd = ('%s run '
> > > > + '--omit "%s" %s %s %s -P1' % (coverage, ','.join(glob_list),
> > > > prog, extra_args or '',
> > > > test_cmd))
> > >
> > > What about using
> > > python3 -m coverage run
> > > instead?
> > > This way we wouldn't rely on the binary name the host distribution chooses
> > > (python3-coverage for Ubuntu, coverage for Fedora).
> > >
> > > I'm not sure there is a need to give the user the ability to override this
> > > value since I expect only coverage.py is supported at the moment?
> >
> > Then you run into the problems that you do not have coverage on
> > python3.4 but only python3.6 or whatever is the relevant version for
> > your distribution ATM.
> >
>
> I don't understand this point? If coverage cannot run with the python from
> the host, then it won't just be possible to run it... so... we don't care?
> Is there something we can do about this I'm missing?
Host can have multiple python versions with varying tools installed.
>
> I would like to advocate for COVERAGE to default to "coverage" or "python3
> -m coverage" since this is more likely to be a sane default for everybody,
> using pip or distro installs.
"coverage" will likely break current test environment but "python3 -m
coverage" may just work, and also test that expanding the arguments
works correctly.
Thanks
Michal
Re: [PATCH v2 1/2] spl: enable regulator-boot-on and disable regulator-force-boot-off
Hello,
On Thu, Sep 01, 2022 at 08:36:23PM +0800, Kever Yang wrote:
> Hi Quentin,
>
> I don't think we need to add regulators_enable_boot_on/off callback in
> SPL framework,
>
> the rk3399-puma/Qseven is the only board need to do this in the SPL right
> now.
>
> The hardware design for SPI/eMMC should always power on the storage
> which
>
> need by very early which should also used by bootrom. And for more device
> power
>
> will be enabled in U-Boot proper.
It's not so clear.
In SPL we have support for loading U-Boot from device other than the one
from which SPL was loaded.
Then it's completely possible for the boot rom to not power on MMC when
loading SPL from SPI NOR, and then SPL may need to power on MMC.
With inside knowledge of the specific boot rom in question you may know
that all boot device are powered on even when not used because the system
was loaded from earlier device in the boot sequence.
Nonetheless, this is not true for all boot roms in general, and on some
platforms loading u-boot from non-boot device may be desirable as well.
Thanks
Michal
>
>
> Thanks,
>
> - Kever
>
> On 2022/7/22 18:09, Quentin Schulz wrote:
> > From: Quentin Schulz
> >
> > This makes sure regulators that need to be turned on or off at boot are
> > turned on or off in the SPL.
> >
> > This may be required for the SPL to do some operations, such as finding
> > possible loading media for U-Boot proper.
> >
> > Cc: Quentin Schulz
> > Tested-by: Xavier Drudis Ferran
> > Signed-off-by: Quentin Schulz
> > ---
> >
> > v2:
> > - added Tested-by,
> > - fixed build for boards with SPL_DM_REGULATOR disabled by always
> > included power/regulator.h and defining a dummy implementation for
> > regulators_enable_boot_off,
> >
> > common/spl/spl.c | 10 ++
> > include/power/regulator.h | 5 +
> > 2 files changed, 15 insertions(+)
> >
> > diff --git a/common/spl/spl.c b/common/spl/spl.c
> > index 29e0898f03..6ab997279d 100644
> > --- a/common/spl/spl.c
> > +++ b/common/spl/spl.c
> > @@ -39,6 +39,7 @@
> > #include
> > #include
> > #include
> > +#include
> > DECLARE_GLOBAL_DATA_PTR;
> > DECLARE_BINMAN_MAGIC_SYM;
> > @@ -773,6 +774,15 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
> > if (CONFIG_IS_ENABLED(GPIO_HOG))
> > gpio_hog_probe_all();
> > + if (CONFIG_IS_ENABLED(DM_REGULATOR)) {
> > + if (regulators_enable_boot_on(false))
> > + debug("%s: Cannot enable boot on regulator\n",
> > + __func__);
> > + if (regulators_enable_boot_off(false))
> > + debug("%s: Cannot enable boot off regulator\n",
> > + __func__);
> > + }
> > +
> > #if CONFIG_IS_ENABLED(BOARD_INIT)
> > spl_board_init();
> > #endif
> > diff --git a/include/power/regulator.h b/include/power/regulator.h
> > index ff1bfc2435..4bce61dd9f 100644
> > --- a/include/power/regulator.h
> > +++ b/include/power/regulator.h
> > @@ -631,6 +631,11 @@ static inline int regulators_enable_boot_on(bool
> > verbose)
> > return -ENOSYS;
> > }
> > +static inline int regulators_enable_boot_off(bool verbose)
> > +{
> > + return -ENOSYS;
> > +}
> > +
> > static inline int regulator_autoset(struct udevice *dev)
> > {
> > return -ENOSYS;
Re: [PATCH 2/2] serial: introduce CONFIG_CONSOLE_FLUSH_ON_NEWLINE
Hello,
On Mon, Sep 25, 2023 at 01:01:01PM +0200, Rasmus Villemoes wrote:
> When debugging, one sometimes only gets partial output lines or
> nothing at all from the last printf, because the uart has a largish
> buffer, and the code after the printf() may cause the CPU to hang
> before the uart IP has time to actually emit all the characters. That
> can be very confusing, because one doesn't then know exactly where the
> hang happens.
>
> Introduce a config knob allowing one to wait for the uart fifo to
> drain whenever a newline character is printed, roughly corresponding
> to the effect of setvbuf(..., _IOLBF, ...) in ordinary C programs.
>
> Signed-off-by: Rasmus Villemoes
> ---
> common/Kconfig | 11 +++
> drivers/serial/serial-uclass.c | 8 ++--
> 2 files changed, 17 insertions(+), 2 deletions(-)
>
> diff --git a/common/Kconfig b/common/Kconfig
> index cdb77a6a7d..49130f2a2b 100644
> --- a/common/Kconfig
> +++ b/common/Kconfig
> @@ -224,6 +224,17 @@ config CONSOLE_FLUSH_SUPPORT
> help
> This enables compilation of flush() function for console flush
> support.
>
> +config CONSOLE_FLUSH_ON_NEWLINE
> + bool "Flush console buffer on every newline character"
> + depends on CONSOLE_FLUSH_SUPPORT
Maybe selects would be more appropriate here if it can be arbitrarily
enabled on any console
> + depends on DM_SERIAL
> + help
> + This makes the serial core code flush the console device
> + whenever a newline (\n) character has been emitted. This can
> + be especially useful when "printf debugging", as otherwise
> + lots of output could still be in the UART's FIFO by the time
> + one hits the code which causes the CPU to hang or reset.
> +
> config CONSOLE_MUX
> bool "Enable console multiplexing"
> default y if VIDEO || LCD
> diff --git a/drivers/serial/serial-uclass.c b/drivers/serial/serial-uclass.c
> index 2f75ff878c..b41e3ebe7f 100644
> --- a/drivers/serial/serial-uclass.c
> +++ b/drivers/serial/serial-uclass.c
> @@ -181,7 +181,6 @@ int serial_initialize(void)
> return serial_init();
> }
>
> -#ifdef CONFIG_CONSOLE_FLUSH_SUPPORT
This should not be removed. CONSOLE_FLUSH_ON_NEWLINE will only ever be
configured when CONFIG_CONSOLE_FLUSH_SUPPORT is also enabled so there is
no need to remove, either.
Thanks
Michal
> static void _serial_flush(struct udevice *dev)
> {
> struct dm_serial_ops *ops = serial_get_ops(dev);
> @@ -191,7 +190,6 @@ static void _serial_flush(struct udevice *dev)
> while (ops->pending(dev, false) > 0)
> ;
> }
> -#endif
>
> static void _serial_putc(struct udevice *dev, char ch)
> {
> @@ -204,6 +202,9 @@ static void _serial_putc(struct udevice *dev, char ch)
> do {
> err = ops->putc(dev, ch);
> } while (err == -EAGAIN);
> +
> + if (IS_ENABLED(CONSOLE_FLUSH_ON_NEWLINE) && ch == '\n')
> + _serial_flush(dev);
> }
>
> static int __serial_puts(struct udevice *dev, const char *str, size_t len)
> @@ -242,6 +243,9 @@ static void _serial_puts(struct udevice *dev, const char
> *str)
> if (*newline && __serial_puts(dev, "\r\n", 2))
> return;
>
> + if (IS_ENABLED(CONSOLE_FLUSH_ON_NEWLINE) && *newline)
> + _serial_flush(dev);
> +
> str += len + !!*newline;
> } while (*str);
> }
> --
> 2.37.2
>
Re: [PATCH] pci: Fix device_find_first_child() return value handling
Hello, On Wed, Jul 26, 2023 at 06:49:57PM -0600, Simon Glass wrote: > Hi Marek, > > On Mon, 17 Jul 2023 at 11:03, Marek Vasut wrote: > > > > On 7/17/23 09:42, Michal Suchánek wrote: ... > > > More generally, what is the overall vision for these functions returning > > > always zero? > > > > > > Should the return value be kept in case the underlying implementation > > > changes and errors can happen in the future, and consequently checked? > > > > > > Should the return value be removed when meaningless making these > > > useless assignments and checks an error? > > > > > > I already elimimnated a return value where using it lead to incorrect > > > behavior but here using it or not is equally correct with the current > > > implementation. > > > > Probably a question for Simon, really. Personally I would be tempted to > > switch the function to return void. > > So long as the function has its meaning documented, I think it is OK. > As a separate patch, I am OK with changing > device_find_first/next_child() to void, or alternatively having them > return 0 on success and -ENODEV if nothing was found. I think when there is one error condition having two ways to report it is one too many. Thanks Michal
Re: Problem upon startup with halted USB device on RaspberryPi 4
Hello,
On Sat, Aug 12, 2023 at 08:31:56PM +0200, Massimo Pegorer wrote:
> Hi Harry,
>
> Il giorno lun 7 ago 2023 alle ore 11:02 Harry Waschkeit <
> harry.waschk...@conplement.de> ha scritto:
>
> > Hi,
> >
> > I have a RaspberryPi 4 where on one USB port a Sierra Wireless LTE
> > module (EM7455) is attached via an PCIe-to-USB adapter.
> > The boot image I use gets built by Yocto with the help of poky
> > (kirkstone) and meta-raspberry (beside a few other layers) which
> > incorporates U-Boot 22.01.
> >
> > When I apply power to the board it will come up until scanning USB
> > devices (for potential boot devices), but then throw a BUG end reset the
> > board.
>
>
> Do you need USB boot devices? If not, I would build U-Boot without USB
> support.
That would be great workaround, However, enabling a device should not
break the board. If that's the case the driver is clearly broken.
Also rPi typically uses USB keyboard for boot-time input which makes the
workaround not so great.
Thanks
Michal
>
> Massimo
>
> > This continues as long as the modem is unplugged.
> > The exact error message is:
> >
> > scanning bus xhci_pci for devices... WARN halted endpoint, queuing URB
> > anyway.
> > Unexpected XHCI event TRB, skipping... (3af519b0 0004 1300
> > 02008401)
> > BUG at drivers/usb/host/xhci-ring.c:503/abort_td()!
> > BUG!
> > resetting ...
> >
> > Some internet research brought up a patch (1) for
> > drivers/usb/host/xhci-ring.c where halted devices simply get ignored
> > during enumeration:
> >
> > diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
> > index acf437104a..6d995f446e 100644
> > --- a/drivers/usb/host/xhci-ring.c
> > +++ b/drivers/usb/host/xhci-ring.c
> > @@ -227,7 +227,8 @@ static int prepare_ring(struct xhci_ctrl *ctrl,
> > struct xhci_ring *ep_ring,
> > puts("WARN waiting for error on ep to be cleared\n");
> > return -EINVAL;
> > case EP_STATE_HALTED:
> > - puts("WARN halted endpoint, queueing URB anyway.\n");
> > + puts("WARN halted endpoint.\n");
> > + return -EPIPE;
> > case EP_STATE_STOPPED:
> > case EP_STATE_RUNNING:
> > debug("EP STATE RUNNING.\n");
> >
> > The driver file itself stems from the Linux sources, so I'm pretty sure
> > that it is correct in that context.
> > Even though I'm not really into USB stuff and therefore I cannot not
> > really follow the discussion for the proposed change, in my eyes the
> > patch could be reasonable for U-Boot nevertheless given that a) in my
> > experience driver code is often used in a simplified way in U-Boot
> > compared to Linux kernel, and b) it's all about board start-up only and
> > not about full OS use with all bells, whistles and full error handling.
> >
> > Of course, I might be wrong while missing some important other use or
> > corner cases, so I wanted to check here :-)
> >
> > At least, what I can say: with this patch I see a bunch of these warning
> > messages but the board comes up and is usable in the end by Linux.
> >
> > fwiw: my internet search also showed another patch labelled in the first
> > place "[PATCH] pi4: fix crash when issuing usb reset" (2) that didn't
> > make it into the particular U-Boot 22.01 but was integrated right after
> > that version in commit "Prepare v2022.04" with hash
> > e4b6ebd3de982ae7185dbf689a030e73fd06e0d2 (3).
> > As I first hoped I could address my problem by just adding this patch I
> > got promptly disappointed. The only thing I gained was to now get
> > endless error messages followed by retries until I power-cycled the
> > board (causing to start all over):
> >
> > USB XHCI 1.00
> > scanning bus xhci_pci for devices... WARN halted endpoint, queueing URB
> > anyway.
> > Unexpected XHCI event TRB, skipping... (3afd6b30 0004 1300
> > 02008401)
> > XHCI abort timeout
> > WARN halted endpoint, queueing URB anyway.
> > Unexpected XHCI event TRB, skipping... (3afd6b40 0004 1300
> > 02008401)
> > XHCI abort timeout
> > WARN halted endpoint, queueing URB anyway.
> > Unexpected XHCI event TRB, skipping... (3afd6b50 0004 1300
> > 02008401)
> > XHCI abort timeout
> > WARN halted endpoint, queueing URB anyway.
> > [...]
> >
> > To me it means that this specific PCIe-to-USB bridge might misbehave
> > somehow,
> > but the final question is: what are the odds to get that patch into
> > official U-boot, or any other fix/quirk to make my hardware combo working?
> >
> > And also interesting: if I cannot hope for an upstream change, what
> > potential risks I would have to accept when keeping my patch?
> >
> > Regards,
> > Harry
> >
> > (1)
> >
> > https://linux-usb.vger.kernel.narkive.com/VW4VTVDU/patch-usb-host-xhci-fix-halted-endpoint-handling
> > (2)
> > https://lore.kernel.org/all/3d4ece94-932a-25dd-ef29-0ddfb4a51...@denx.de/T/
> > (3)
> >
> > https://source.denx.de/u-boot/u-boot/-/commit/e4b6ebd3de982ae7185dbf689a030e73fd06e0d2
> >
> > --
> > i.A. Harry Waschkeit
> > Senior Embedded Engineer
> > conplement AG
> > Südwestpark 92
> > 90449 Nürn
Re: [PATCH] rockchip: rk3399: pass platform parameter to TF-A by default
Hello,
On Sun, Dec 18, 2022 at 06:00:13PM +0800, Kever Yang wrote:
> Hi Quentin,
>
> I would prefer you to remove SPL_ATF_NO_PLATFORM_PARAM in those boards
> you have test,
then we will have no end of this problem.
>
> there may have some boards using legacy ATF binary but still want to use
> mainline U-Boot
Why would they do it?
The ATF is SoC-specific, the only board-specific part is the console
speed which is resolved by this change.
If people are using old kernel because they have binary driver for a
special device they can still change the option in the kconfig.
Maybe adding a note in the rk3399 documentation woukl be dessirable but
that's about it.
Thanks
Michal
>
> which may have problem with this update.
>
>
> Thanks,
>
> - Kever
>
> On 2022/11/15 01:37, Quentin Schulz wrote:
> > From: Quentin Schulz
> >
> > Long are gone the times TF-A couldn't handle the FDT passed by U-Boot.
> > Specifically, since commit e7b586987c0a ("rockchip: don't crash if we
> > get an FDT we can't parse") in TF-A, failure to parse the FDT will use
> > the fallback mechanism. This patch was merged in TF-A v2.4-rc0 from two
> > years ago.
> >
> > Therefore, let's finally pass the FDT to TF-A so that it can get the
> > serial configuration from U-Boot FDT instead of requiring the user to
> > patch TF-A hardcoded fallback values.
> >
> > Cc: Quentin Schulz
> > Signed-off-by: Quentin Schulz
> > ---
> > rockchip: rk3399: pass platform parameter to TF-A
> >
> > Finally pass the FDT address to TF-A since it now gracefully fallbacks to
> > hardcoded defaults if it cannot parse it. This allows us to avoid modifying
> > hardcoded values in TF-A to enable the console.
> >
> > This was tested with TF-A v2.7.0 on Puma Haikou RK3399.
> >
> > To: Simon Glass
> > To: Philipp Tomsich
> > To: Kever Yang
> > Cc: Hugh Cole-Baker
> > Cc: Walter Lozano
> > Cc: u-boot@lists.denx.de
> > ---
> > arch/arm/mach-rockchip/Kconfig | 1 -
> > 1 file changed, 1 deletion(-)
> >
> > diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
> > index 69d51ff378..2fcc23f9fa 100644
> > --- a/arch/arm/mach-rockchip/Kconfig
> > +++ b/arch/arm/mach-rockchip/Kconfig
> > @@ -249,7 +249,6 @@ config ROCKCHIP_RK3399
> > imply PRE_CONSOLE_BUFFER
> > imply ROCKCHIP_COMMON_BOARD
> > imply ROCKCHIP_SDRAM_COMMON
> > - imply SPL_ATF_NO_PLATFORM_PARAM if SPL_ATF
> > imply SPL_ROCKCHIP_COMMON_BOARD
> > imply TPL_SERIAL
> > imply TPL_LIBCOMMON_SUPPORT
> >
> > ---
> > base-commit: 0cbeed4f6648e0e4966475e3544280a69ecb59d3
> > change-id: 20221114-rk3399-tf-a-plat-param-3ab055f40b9e
> >
> > Best regards,
Re: [PATHv11 01/43] submodule: add lwIP as git submodule
Hello, On Wed, Nov 29, 2023 at 07:45:28PM -0700, Simon Glass wrote: > Hi Tom, > > On Mon, 27 Nov 2023 at 11:16, Tom Rini wrote: > > > > On Mon, Nov 27, 2023 at 06:56:44PM +0600, Maxim Uvarov wrote: > > > > > add external lwIP library as a git submodule. > > > Use STABLE-2_2_0_RELEASE tag. > > > > > > Signed-off-by: Maxim Uvarov > > > > And just for the record, we'll re-visit submodule/subtree/whatever later > > on, this (and the final parts for CI to be happy about it) are a means > > to an end. > > While I understand this, I would still like to see a patch containing > the actual code. We are at v11 here. This is why submodules are evil. You *can* produce a patch that contains the code but you have to *remember* to pass the argument. And if the patch does contains the code it is likely not applicable because then it does not contain the revision to which the submodule should be updated. Submoudules may be a generally good idea but they are not well implemented in git. Thanks Michal
SPI bus not probed
Hello,
When I enable SPI support I do not get a SPI bus.
Config:
--- a/configs/orangepi_zero_defconfig
+++ b/configs/orangepi_zero_defconfig
@@ -11,3 +11,21 @@ CONFIG_CONSOLE_MUX=y
CONFIG_SUN8I_EMAC=y
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_OHCI_HCD=y
+CONFIG_SPI=y
+CONFIG_DM_SPI=y
+CONFIG_DM_SPI_FLASH=y
+CONFIG_SPI_FLASH=y
+CONFIG_CMD_SPI=y
+CONFIG_CMD_SF_TEST=y
+CONFIG_SPI_FLASH_SFDP_SUPPORT=y
+CONFIG_SPI_FLASH_ATMEL=y
+CONFIG_SPI_FLASH_EON=y
+CONFIG_SPI_FLASH_GIGADEVICE=y
+CONFIG_SPI_FLASH_ISSI=y
+CONFIG_SPI_FLASH_MACRONIX=y
+CONFIG_SPI_FLASH_SPANSION=y
+CONFIG_SPI_FLASH_STMICRO=y
+CONFIG_SPI_FLASH_SST=y
+CONFIG_SPI_FLASH_WINBOND=y
+CONFIG_SPI_FLASH_XMC=y
+CONFIG_SPI_FLASH_DATAFLASH=y
DT (which lists the flash types so did not really have to enable them all)
--- a/arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts
+++ b/arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts
@@ -163,10 +163,11 @@
};
&spi0 {
- /* Disable SPI NOR by default: it optional on Orange Pi Zero boards */
- status = "disabled";
+ /* Enable SPI NOR by default: it optional on Orange Pi Zero boards */
+ status = "okay";
flash@0 {
+status = "okay";
#address-cells = <1>;
#size-cells = <1>;
compatible = "mxicy,mx25l1606e", "winbond,w25q128";
The guide on debugging says to add dm_dump_all
--- a/drivers/spi/spi-uclass.c
+++ b/drivers/spi/spi-uclass.c
@@ -328,6 +328,7 @@ int spi_get_bus_and_cs(int busnum, int cs, int speed, int
mode,
bool created = false;
int ret;
+dm_dump_all();
#if CONFIG_IS_ENABLED(OF_PLATDATA)
ret = uclass_first_device_err(UCLASS_SPI, &bus);
#else
which prints
Class Index Probed DriverName
---
root 0 [ + ] root_driver root_driver
simple_bus0 [ + ] simple_bus|-- soc
mmc 0 [ + ] sunxi_mmc | |-- mmc@1c0f000
blk 0 [ ] mmc_blk | | `-- m...@1c0f000.blk
mmc 1 [ + ] sunxi_mmc | |-- mmc@1c1
blk 1 [ ] mmc_blk | | `-- m...@1c1.blk
phy 0 [ ] sun4i_usb_phy | |-- phy@1c19400
usb 0 [ ] ehci_generic | |-- usb@1c1a000
usb 1 [ ] ohci_generic | |-- usb@1c1a400
usb 2 [ ] ehci_generic | |-- usb@1c1b000
usb 3 [ ] ohci_generic | |-- usb@1c1b400
clk 0 [ + ] sun8i_h3_ccu | |-- clock@1c2
reset 0 [ + ] sunxi_reset | | `-- reset
gpio 0 [ + ] gpio_sunxi| |-- pinctrl@1c20800
gpio 1 [ + ] gpio_sunxi| | |-- PA
gpio 2 [ + ] gpio_sunxi| | |-- PB
gpio 3 [ + ] gpio_sunxi| | |-- PC
gpio 4 [ + ] gpio_sunxi| | |-- PD
gpio 5 [ + ] gpio_sunxi| | |-- PE
gpio 6 [ + ] gpio_sunxi| | |-- PF
gpio 7 [ + ] gpio_sunxi| | |-- PG
gpio 8 [ + ] gpio_sunxi| | |-- PH
gpio 9 [ + ] gpio_sunxi| | `-- PI
eth 0 [ + ] eth_sun8i_emac| |-- ethernet@1c3
spi 0 [ ] sun4i_spi | |-- spi@1c68000
serial0 [ + ] ns16550_serial| |-- serial@1c28000
gpio 10 [ + ] gpio_sunxi| `-- pinctrl@1f02c00
gpio 11 [ + ] gpio_sunxi| `-- PL
clk 1 [ + ] fixed_rate_clock |-- osc24M_clk
clk 2 [ ] fixed_rate_clock `-- osc32k_clk
Invalid bus 0 (err=-19)
-19 means ENODEV according to my /usr/include/asm-generic/errno-base.h
Debug prints added to sunxi driver are never printed:
--- a/drivers/spi/spi-sunxi.c
+++ b/drivers/spi/spi-sunxi.c
@@ -305,6 +305,7 @@ static int sun4i_spi_claim_bus(struct udevice *dev)
{
struct sun4i_spi_priv *priv = dev_get_priv(dev->parent);
int ret;
+ printf("sun4i_spi_claim_bus\n");
ret = sun4i_spi_set_clock(dev->parent, true);
if (ret)
@@ -487,6 +488,8 @@ static int sun4i_spi_probe(struct udevice *bus)
struct sun4i_spi_priv *priv = dev_get_priv(bus);
int ret;
+ printf("sun4i_spi_probe\n");
+
ret = clk_get_by_name(bus, "ahb", &priv->clk_ahb);
if (ret) {
dev_err(dev, "failed to get ahb clock\n");
AFAICT the device tree compatible matches the one in the driver.
How do I make u-boot run the driver?
Thanks
Michal
Re: SPI bus not probed
On Sun, Sep 27, 2020 at 10:35:30PM +0200, Michal Suchánek wrote:
> Hello,
>
> When I enable SPI support I do not get a SPI bus.
>
> Config:
> --- a/configs/orangepi_zero_defconfig
> +++ b/configs/orangepi_zero_defconfig
> @@ -11,3 +11,21 @@ CONFIG_CONSOLE_MUX=y
> CONFIG_SUN8I_EMAC=y
> CONFIG_USB_EHCI_HCD=y
> CONFIG_USB_OHCI_HCD=y
> +CONFIG_SPI=y
> +CONFIG_DM_SPI=y
> +CONFIG_DM_SPI_FLASH=y
> +CONFIG_SPI_FLASH=y
> +CONFIG_CMD_SPI=y
> +CONFIG_CMD_SF_TEST=y
> +CONFIG_SPI_FLASH_SFDP_SUPPORT=y
> +CONFIG_SPI_FLASH_ATMEL=y
> +CONFIG_SPI_FLASH_EON=y
> +CONFIG_SPI_FLASH_GIGADEVICE=y
> +CONFIG_SPI_FLASH_ISSI=y
> +CONFIG_SPI_FLASH_MACRONIX=y
> +CONFIG_SPI_FLASH_SPANSION=y
> +CONFIG_SPI_FLASH_STMICRO=y
> +CONFIG_SPI_FLASH_SST=y
> +CONFIG_SPI_FLASH_WINBOND=y
> +CONFIG_SPI_FLASH_XMC=y
> +CONFIG_SPI_FLASH_DATAFLASH=y
>
> DT (which lists the flash types so did not really have to enable them all)
> --- a/arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts
> +++ b/arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts
> @@ -163,10 +163,11 @@
> };
>
> &spi0 {
> - /* Disable SPI NOR by default: it optional on Orange Pi Zero boards */
> - status = "disabled";
> + /* Enable SPI NOR by default: it optional on Orange Pi Zero boards */
> + status = "okay";
>
> flash@0 {
> +status = "okay";
> #address-cells = <1>;
> #size-cells = <1>;
> compatible = "mxicy,mx25l1606e", "winbond,w25q128";
>
> The guide on debugging says to add dm_dump_all
> --- a/drivers/spi/spi-uclass.c
> +++ b/drivers/spi/spi-uclass.c
> @@ -328,6 +328,7 @@ int spi_get_bus_and_cs(int busnum, int cs, int speed, int
> mode,
> bool created = false;
> int ret;
>
> +dm_dump_all();
> #if CONFIG_IS_ENABLED(OF_PLATDATA)
> ret = uclass_first_device_err(UCLASS_SPI, &bus);
> #else
>
> which prints
>
> Class Index Probed DriverName
> ---
> root 0 [ + ] root_driver root_driver
> simple_bus0 [ + ] simple_bus|-- soc
> mmc 0 [ + ] sunxi_mmc | |-- mmc@1c0f000
> blk 0 [ ] mmc_blk | | `-- m...@1c0f000.blk
> mmc 1 [ + ] sunxi_mmc | |-- mmc@1c1
> blk 1 [ ] mmc_blk | | `-- m...@1c1.blk
> phy 0 [ ] sun4i_usb_phy | |-- phy@1c19400
> usb 0 [ ] ehci_generic | |-- usb@1c1a000
> usb 1 [ ] ohci_generic | |-- usb@1c1a400
> usb 2 [ ] ehci_generic | |-- usb@1c1b000
> usb 3 [ ] ohci_generic | |-- usb@1c1b400
> clk 0 [ + ] sun8i_h3_ccu | |-- clock@1c2
> reset 0 [ + ] sunxi_reset | | `-- reset
> gpio 0 [ + ] gpio_sunxi| |-- pinctrl@1c20800
> gpio 1 [ + ] gpio_sunxi| | |-- PA
> gpio 2 [ + ] gpio_sunxi| | |-- PB
> gpio 3 [ + ] gpio_sunxi| | |-- PC
> gpio 4 [ + ] gpio_sunxi| | |-- PD
> gpio 5 [ + ] gpio_sunxi| | |-- PE
> gpio 6 [ + ] gpio_sunxi| | |-- PF
> gpio 7 [ + ] gpio_sunxi| | |-- PG
> gpio 8 [ + ] gpio_sunxi| | |-- PH
> gpio 9 [ + ] gpio_sunxi| | `-- PI
> eth 0 [ + ] eth_sun8i_emac| |-- ethernet@1c3
> spi 0 [ ] sun4i_spi | |-- spi@1c68000
> serial0 [ + ] ns16550_serial| |-- serial@1c28000
> gpio 10 [ + ] gpio_sunxi| `-- pinctrl@1f02c00
> gpio 11 [ + ] gpio_sunxi| `-- PL
> clk 1 [ + ] fixed_rate_clock |-- osc24M_clk
> clk 2 [ ] fixed_rate_clock `-- osc32k_clk
> Invalid bus 0 (err=-19)
>
> -19 means ENODEV according to my /usr/include/asm-generic/errno-base.h
>
> Debug prints added to sunxi driver are never printed:
>
> --- a/drivers/spi/spi-sunxi.c
> +++ b/drivers/spi/spi-sunxi.c
> @@ -305,6 +305,7 @@ static int sun4i_spi_claim_bus(struct udevice *dev)
> {
> struct sun4i_spi_priv *priv = dev_get_priv(dev->parent);
> int ret;
> + printf("sun4i_spi_claim_bus\n");
>
> ret = sun4i_spi_set_clock(dev->parent, true);
> if (ret)
> @@
Re: [PATCH 00/18] Add support for MediaTek MT7620 SoC
Hello, I would suggest to use --thread with format-patch when sending patches. Thanks Michal On Fri, Oct 16, 2020 at 03:35:01PM +0800, Weijie Gao wrote: > This series will add support for MediaTek MT7620 SoC with two reference boards > and related drivers. > > The MediaTek MT7620 is a 2x2 802.11n WiSoC integrating a MIPS 24KEc processor > running at a maximum frequency of 620MHz. This chip can be found in many > wireless routers. > > This series add all basic drivers which are useful in u-boot, like usb, sdhc, > ethernet, spi and serial. Booting from NAND is currently unsupported. > > Thanks, > Weijie > > Weijie Gao (18): > mips: dts: switch to board defines for dtb for mtmips > mips: mtmips: move mt7628 related Kconfig into mt7628 subdirectory > mips: mtmips: fix dram size detection in dram_init > mips: mtmips: add support to initialize SDRAM > mips: mtmips: add support for MediaTek MT7620 SoC > mips: mtmips: add two reference boards for mt7620 > configs: mtmips: refresh for mt7628 based boards > serial: add uart driver for MediaTek MT7620 SoC > clk: add clock driver for MediaTek MT7620 SoC > reset: mtmips: add reset controller support for MediaTek MT7620 SoC > pinctrl: mtmips: add support for MediaTek MT7620 SoC > watchdog: add watchdog driver for MediaTek MT7620 SoC > gpio: add GPIO controller driver for MediaTek MT7620 SoC > spi: add spi controller support for MediaTek MT7620 SoC > phy: add USB PHY driver for MediaTek MT7620 SoC > net: add ethernet driver for MediaTek MT7620 SoC > mmc: mtk-sd: add pad control settings for MediaTek MT7620/MT76x8 SoCs > MAINTAINERS: add maintainer for MediaTek MIPS platform > > MAINTAINERS | 23 + > arch/mips/dts/Makefile|7 +- > arch/mips/dts/mediatek,mt7620-mt7530-rfb.dts | 100 ++ > arch/mips/dts/mediatek,mt7620-rfb.dts | 97 ++ > arch/mips/dts/mt7620-u-boot.dtsi | 38 + > arch/mips/dts/mt7620.dtsi | 302 > arch/mips/mach-mtmips/Kconfig | 75 +- > arch/mips/mach-mtmips/Makefile|1 + > arch/mips/mach-mtmips/cpu.c |5 +- > arch/mips/mach-mtmips/ddr_init.c | 59 + > arch/mips/mach-mtmips/include/mach/ddr.h |4 + > .../mach-mtmips/include/mach/mt7620-sysc.h| 54 + > arch/mips/mach-mtmips/mt7620/Kconfig | 71 + > arch/mips/mach-mtmips/mt7620/Makefile | 10 + > arch/mips/mach-mtmips/mt7620/dram.c | 114 ++ > arch/mips/mach-mtmips/mt7620/init.c | 185 +++ > arch/mips/mach-mtmips/mt7620/lowlevel_init.S | 53 + > arch/mips/mach-mtmips/mt7620/mt7620.h | 102 ++ > arch/mips/mach-mtmips/mt7620/serial.c | 37 + > arch/mips/mach-mtmips/mt7620/sysc.c | 171 +++ > arch/mips/mach-mtmips/mt7628/Kconfig | 53 + > board/mediatek/mt7620/Kconfig | 20 + > board/mediatek/mt7620/MAINTAINERS |9 + > board/mediatek/mt7620/Makefile|3 + > board/mediatek/mt7620/board.c |8 + > .../gardena-smart-gateway-mt7688_defconfig|1 + > configs/linkit-smart-7688_defconfig |1 + > configs/mt7620_mt7530_rfb_defconfig | 52 + > configs/mt7620_rfb_defconfig | 68 + > configs/mt7628_rfb_defconfig |1 + > configs/vocore2_defconfig |1 + > drivers/clk/mtmips/Makefile |1 + > drivers/clk/mtmips/clk-mt7620.c | 154 +++ > drivers/gpio/Kconfig |8 + > drivers/gpio/Makefile |1 + > drivers/gpio/mt7620_gpio.c| 146 ++ > drivers/mmc/mtk-sd.c | 122 +- > drivers/net/Kconfig | 12 + > drivers/net/Makefile |1 + > drivers/net/mt7620-eth.c | 1222 + > drivers/phy/Kconfig |7 + > drivers/phy/Makefile |1 + > drivers/phy/mt7620-usb-phy.c | 108 ++ > drivers/pinctrl/mtmips/Kconfig|9 + > drivers/pinctrl/mtmips/Makefile |1 + > drivers/pinctrl/mtmips/pinctrl-mt7620.c | 199 +++ > drivers/serial/Kconfig| 20 + > drivers/serial/Makefile |1 + > drivers/serial/serial.c |2 + > drivers/serial/serial_mt7620.c| 350 + > drivers/spi/Kconfig |7 + > drivers/spi/Makefile |1 + > drivers/spi/mt7620_spi.c | 277 > drivers/watchdog/Kconfig |7 + > drivers/watchdog/Makefile |1 + > drivers/watchdog/mt7620_wdt.c | 119 ++ > include/configs/mt7
rk3399 after reboot mmc1 is inaceessible
Hello, after rebooting rk3399 Pinebook Pro mmc1 is no longer accessible from u-boot, and video is not working, only cold boot works. This is not a problem anymore when Linux is loaded from another device. Any idea how to debug this? Thanks Michal U-Boot TPL 2022.07-rc5 (May 16 2022 - 12:00:00) Channel 0: LPDDR4, 50MHz BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB Channel 1: LPDDR4, 50MHz BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB 256B stride lpddr4_set_rate: change freq to 4 mhz 0, 1 lpddr4_set_rate: change freq to 8 mhz 1, 0 Trying to boot from BOOTROM Returning to boot ROM... U-Boot SPL 2022.07-rc5 (May 16 2022 - 12:00:00 +) Trying to boot from MMC1 NOTICE: BL31: v2.6(debug): NOTICE: BL31: Built : 14:50:40, Jul 1 2022 INFO:GICv3 with legacy support detected. INFO:ARM GICv3 driver initialized in EL3 INFO:Maximum SPI INTID supported: 287 INFO:plat_rockchip_pmu_init(1624): pd status 3e INFO:BL31: Initializing runtime services INFO:BL31: cortex_a53: CPU workaround for 855873 was applied WARNING: BL31: cortex_a53: CPU workaround for 1530924 was missing! INFO:BL31: Preparing for EL3 exit to normal world INFO:Entry point address = 0x20 INFO:SPSR = 0x3c9 U-Boot 2022.07-rc5 (May 16 2022 - 00:00:00 +) SoC: Rockchip rk3399 Reset cause: POR Model: Pine64 Pinebook Pro DRAM: 3.9 GiB PMIC: RK808 Core: 317 devices, 34 uclasses, devicetree: separate MMC: mmc@fe31: 3, mmc@fe32: 1, mmc@fe33: 0 Loading Environment from SPIFlash... SF: Detected gd25q128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB *** Warning - bad CRC, using default environment In:serial Out: vidconsole Err: vidconsole Model: Pine64 Pinebook Pro Net: No ethernet found. starting USB... Bus usb@fe38: ehci_generic usb@fe38: Failed to get clocks (ret=-19) Port not available. Bus usb@fe3a: USB OHCI 1.0 Bus usb@fe3c: ehci_generic usb@fe3c: Failed to get clocks (ret=-19) Port not available. Bus usb@fe3e: USB OHCI 1.0 Bus usb@fe80: Register 2000140 NbrPorts 2 Starting the controller USB XHCI 1.10 Bus usb@fe90: Register 2000140 NbrPorts 2 Starting the controller USB XHCI 1.10 scanning bus usb@fe3a for devices... 2 USB Device(s) found scanning bus usb@fe3e for devices... 4 USB Device(s) found scanning bus usb@fe80 for devices... 1 USB Device(s) found scanning bus usb@fe90 for devices... 1 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc1 is current device ** Invalid partition 3 ** Couldn't find partition mmc 1:3 ** Invalid partition 4 ** Couldn't find partition mmc 1:4 Scanning mmc 1:1... BootOrder not defined EFI boot manager: Cannot load any image Found EFI removable media binary efi/boot/bootaa64.efi 857968 bytes read in 96 ms (8.5 MiB/s) Booting /efi\boot\bootaa64.efi U-Boot TPL 2022.07-rc5 (May 16 2022 - 12:00:00) Channel 0: LPDDR4, 50MHz BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB Channel 1: LPDDR4, 50MHz BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB 256B stride lpddr4_set_rate: change freq to 4 mhz 0, 1 lpddr4_set_rate: change freq to 8 mhz 1, 0 Trying to boot from BOOTROM Returning to boot ROM... U-Boot SPL 2022.07-rc5 (May 16 2022 - 12:00:00 +) Trying to boot from MMC1 NOTICE: BL31: v2.6(debug): NOTICE: BL31: Built : 14:50:40, Jul 1 2022 INFO:GICv3 with legacy support detected. INFO:ARM GICv3 driver initialized in EL3 INFO:Maximum SPI INTID supported: 287 INFO:plat_rockchip_pmu_init(1624): pd status 3e INFO:BL31: Initializing runtime services INFO:BL31: cortex_a53: CPU workaround for 855873 was applied WARNING: BL31: cortex_a53: CPU workaround for 1530924 was missing! INFO:BL31: Preparing for EL3 exit to normal world INFO:Entry point address = 0x20 INFO:SPSR = 0x3c9 U-Boot 2022.07-rc5 (May 16 2022 - 00:00:00 +) SoC: Rockchip rk3399 Reset cause: RST Model: Pine64 Pinebook Pro DRAM: 3.9 GiB PMIC: RK808 Core: 317 devices, 34 uclasses, devicetree: separate MMC: mmc@fe31: 3, mmc@fe32: 1, mmc@fe33: 0 Loading Environment from SPIFlash... SF: Detected gd25q128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB *** Warning - bad CRC, using default environment In:serial Out: vidconsole Err: vidconsole Model: Pine64 Pinebook Pro Net: No ethernet found. starting USB... Bus usb@fe38: ehci_generic usb@fe38: Failed to get clocks (ret=-19) Port not available. Bus usb@fe3a: USB OHCI 1.0 Bus usb@fe3c: ehci_generic usb@fe3c: Failed to get clocks (ret=-19) Port not available. Bus usb@fe3e: USB OHCI 1.0 Bus usb@fe80: Register 2000140 NbrPorts 2 Starting the controller USB XHCI 1.10 Bus usb@fe90: Register 2000140 NbrPorts 2 Starting the controller USB XHCI 1.10 scanning bus usb@fe3a
Re: [PATCH 2/2] cmd: boot: add brom cmd to reboot to FEL mode
Hello,
On Sun, Jul 03, 2022 at 11:23:26PM +0100, Andre Przywara wrote:
> On Sun, 3 Jul 2022 21:20:22 +0200
> Michal Suchanek wrote:
>
> Hi Michal,
>
> > p-boot uses RTC GPR 1 value 0xb0010fe1 to flag FEL boot on A64
> >
> > Default to the same.
>
> Please don't add any more #ifdef's to U-Boot, especially no nested
> ones, there are already far too many.
I'm sure that the ifdefs can be reduced if the code is cleaned up.
>
> > Signed-off-by: Michal Suchanek
> > ---
> > arch/arm/include/asm/arch-sunxi/cpu.h | 11 +++
> > arch/arm/mach-sunxi/Kconfig | 18 ++
> > arch/arm/mach-sunxi/board.c | 24
> > cmd/boot.c| 17 -
> > 4 files changed, 69 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/include/asm/arch-sunxi/cpu.h
> > b/arch/arm/include/asm/arch-sunxi/cpu.h
> > index b08f202374..36e7697b1c 100644
> > --- a/arch/arm/include/asm/arch-sunxi/cpu.h
> > +++ b/arch/arm/include/asm/arch-sunxi/cpu.h
> > @@ -20,4 +20,15 @@
> > #define SOCID_H5 0x1718
> > #define SOCID_R40 0x1701
> >
> > +#if defined(CONFIG_SUNXI_RTC_FEL_ENTRY_GPR) &&
> > (CONFIG_SUNXI_RTC_FEL_ENTRY_GPR >= 0)
> > +#ifdef CONFIG_MACH_SUN8I_H3
> > +#define SUNXI_FEL_ENTRY_ADDRESS 0x0020
>
> That is actually SUNXI_BROM_BASE + 0x20, regardless of the SoC. Only
> that the SUNXI_BROM_BASE is wrong for newer SoC, but anyway ...
Which means that it needs to be defined, anyway.
>
> > +#define SUNXI_RTC_GPR_OFFSET 0x100
> > +#define SUNXI_FEL_REG (SUNXI_RTC_BASE + SUNXI_RTC_GPR_OFFSET +
> > CONFIG_SUNXI_RTC_FEL_ENTRY_GPR * 4)
> > +#endif
> > +#endif
>
> In general there is no need to protect #defines, unless you actually
> depend on another symbol. More importantly, as there is only one user,
I don't want to define SUNXI_FEL_REG when CONFIG_SUNXI_RTC_FEL_ENTRY_GPR
is -1, and I want to detect the feature availability which is currently
done by detecting SUNXI_FEL_REG.
> in a platform specific command, those defines are better held in the
> implementation. cpu*.h is actually legacy code, and I have patches to cut
> it down significantly, eventually possibly removing it altogether.
The implementation has multiple parts, and SUNXI_FEL_REG is used by all
of them. Also SUNXI_RTC_BASE is defined in cpu.h so anything that
depends on it logically belongs there.
>
> > +#ifndef __ASSEMBLY__
> > +void set_rtc_fel_flag(void);
> > +#endif
> > +
> > #endif /* _SUNXI_CPU_H */
> > diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> > index e712a89534..10645fc644 100644
> > --- a/arch/arm/mach-sunxi/Kconfig
> > +++ b/arch/arm/mach-sunxi/Kconfig
> > @@ -1048,6 +1048,24 @@ source "board/sunxi/Kconfig"
> >
> > endif
> >
> > +if MACH_SUN8I_H3 || MACH_SUN50I
>
> I don't think if's in Kconfig are customary. Just use "depends on"
> inside.
Sure, then there is no need for matching endif then, easier to maintain.
>
> > +config SUNXI_RTC_FEL_ENTRY_GPR
> > + int "Use a RTC GPR to enter FEL"
> > + range -1 7 if MACH_SUN8I_H3
> > + range -1 3 if MACH_SUN50I
>
> The current code does not work easily with 64-bit SoCs, so we can
> add this later.
IS the problem that you need to run FEL in 32bit but this code runs in
64bit?
> But also IIRC there are actually eight GPRs in the A64 RTC, despite
> what the manual says, as someone found out by experimentation.
>
> > + default 1
> > + help
> > + Add rbrom command to set a RTC general purpose register before reboot.
> > + Check the GPR value in SPL and jump to FEL if set.
> > + Value -1 disables the feature.
> > +
> > +config SUNXI_RTC_FEL_ENTRY_VALUE
> > + hex "Value to set in the RTC GPR"
> > + depends on SUNXI_RTC_FEL_ENTRY_GPR >= 0
> > + range 0x1 0x
> > + default 0xb0010fe1
> > +endif
> > +
> > config CHIP_DIP_SCAN
> > bool "Enable DIPs detection for CHIP board"
> > select SUPPORT_EXTENSION_SCAN
> > diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
> > index 8f7c894286..91866a3be6 100644
> > --- a/arch/arm/mach-sunxi/board.c
> > +++ b/arch/arm/mach-sunxi/board.c
> > @@ -297,7 +297,30 @@ uint32_t sunxi_get_boot_device(void)
> > return -1; /* Never reached */
> > }
> >
> > +void set_rtc_fel_flag(void)
> > +{
> > +#ifdef SUNXI_FEL_REG
> > + volatile long *check_reg = (void *)SUNXI_FEL_REG;
> > +
> > + *check_reg = CONFIG_SUNXI_RTC_FEL_ENTRY_VALUE;
>
> Please don't let the compiler write to an MMIO device. We have writel
> for that purpose.
Right, it's an interesting question if writing only part of the register
would work but this is not the code where it should be tested.
>
> > +#endif
> > +}
> > +
> > #ifdef CONFIG_SPL_BUILD
> > +
> > +void check_rtc_fel_flag(void)
> > +{
> > +#ifdef SUNXI_FEL_REG
> > + volatile long *check_reg = (void *)SUNXI_FEL_REG;
> > + void (*entry)(void) = (void*)SUNXI_FEL_ENTRY_ADDRESS;
> > +
> > + if (*check_reg == CONFIG_SUNXI_
Re: [PATCH 0/2] Command for entering mask rom USB download mode
On Sun, Jul 03, 2022 at 11:22:51PM +0100, Andre Przywara wrote: > On Sun, 3 Jul 2022 21:20:20 +0200 > Michal Suchanek wrote: > > Hi, > > > many ARM SoCs have a mask rom feature that provides interface for > > downloading firmware over USB. > > > > Downstream rockchip u-boot has 'brom' or 'rbrom' command for this > > purpose, and downstream sunxi u-boot provides 'efex' command. p-boot has > > code for entering FEL on A64 SoC. > > Thanks for bringing this up. We have discussed several options before, > including some true FEL reset commands, which do not depend on the SPL > doing the branch. > But I guess we can just start with this one and expand it from there. > > > With this patch I am able to activate the USB downloader on a rk3399 but > > the rkflashtool fails to communicate with the device. On a H2+ I can get > > into the FEL mode and get flash parameters. YMMV > > > > I don't have any great idea how to structure this so that the command > > does not need platform-specific code. Is there an example of a command > > that has platform-specific implementations? > > I don't think that's a problem: there are already platform specific > commands, you just put them in a separate file and mark them as > "depends on ARCH_SUNXI" (or whatever) in cmd/Kconfig and be done. No > need to boil the ocean here in trying to be generic. > That's why I wouldn't put them in cmd/boot.c, especially since you > don't seem to share any code? The reset implementation also does not share any actual code between platforms, has different implementation on each platform, and is cross-platform command that provides the same functionality on each paltform. Because the functionality can be provided on multiple platfroms the goal is to provide cross-platform user interface for it. Thanks Michal
Re: [PATCH 0/2] Command for entering mask rom USB download mode
On Sun, Jul 03, 2022 at 06:26:22PM -0500, Samuel Holland wrote: > Hi Michal, > > On 7/3/22 2:20 PM, Michal Suchanek wrote: > > > > Hello, > > > > many ARM SoCs have a mask rom feature that provides interface for > > downloading firmware over USB. > > > > Downstream rockchip u-boot has 'brom' or 'rbrom' command for this > > purpose, and downstream sunxi u-boot provides 'efex' command. p-boot has > > code for entering FEL on A64 SoC. > > > > With this patch I am able to activate the USB downloader on a rk3399 but > > the rkflashtool fails to communicate with the device. On a H2+ I can get > > into the FEL mode and get flash parameters. YMMV > > > > I don't have any great idea how to structure this so that the command > > does not need platform-specific code. Is there an example of a command > > that has platform-specific implementations? > > Generally you would do this by having the driver interact with some DM uclass. > Platforms may or may not provide a driver implementing that uclass; the > details > are hidden behind the uclass's interface. All the command has to do is search > for a DM device by uclass, and if one is found, call some operation on it. > > In this case, UCLASS_REBOOT_MODE already exists. It sounds like what we need > is > the inverse of dm_reboot_mode_update() -- a function that takes a string and > programs the device with the corresponding mode value. > > To be generic, you could call this function from do_reset() if some positional > argument is provided, allowing usage like "reset bootloader" or "reset fel". > > Rockchip platforms already have syscon-reboot-mode hooked up in their > devicetrees. The driver for this should be trivial. > > Allwinner platforms would need to add a nvmem-reboot-mode node, and a bit more > driver infrastructure. U-Boot does not have NVMEM uclass, so you would need to > add one or reuse UCLASS_MISC. Not sure I understand the DM enough but as firt step I can at least hook it to the do_reset function. Thanks Michal
Re: [PATCH v2 1/2] power: pmic: rk8xx: Support sysreset shutdown method
Hello,
this causes regression on pinebook pro:
resetting ...
System reset not supported on this platform
### ERROR ### Please RESET the board ###
Is there something missing in the DT for this board?
Or perhaps a fallback should be provided in absence of the PMIC?
Thanks
Michal
On Fri, May 27, 2022 at 01:18:19PM -0500, Chris Morgan wrote:
> From: Chris Morgan
>
> Add support for sysreset shutdown for this PMIC. The values were pulled
> from the various datasheets, but for now it has only been tested on
> the rk817 (for an Odroid Go Advance).
>
> Signed-off-by: Chris Morgan
> Reviewed-by: Jaehoon Chung
> Reviewed-by: Kever Yang
> ---
> drivers/power/pmic/rk8xx.c | 50 +-
> 1 file changed, 49 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/power/pmic/rk8xx.c b/drivers/power/pmic/rk8xx.c
> index 5f442fea68..1ffbecc02a 100644
> --- a/drivers/power/pmic/rk8xx.c
> +++ b/drivers/power/pmic/rk8xx.c
> @@ -6,10 +6,50 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include
> #include
> +#include
> +
> +static int rk8xx_sysreset_request(struct udevice *dev, enum sysreset_t type)
> +{
> + struct rk8xx_priv *priv = dev_get_priv(dev->parent);
> +
> + if (type != SYSRESET_POWER_OFF)
> + return -EPROTONOSUPPORT;
> +
> + switch (priv->variant) {
> + case RK805_ID:
> + case RK808_ID:
> + case RK816_ID:
> + case RK818_ID:
> + pmic_clrsetbits(dev->parent, REG_DEVCTRL, 0, BIT(0));
> + break;
> + case RK809_ID:
> + case RK817_ID:
> + pmic_clrsetbits(dev->parent, RK817_REG_SYS_CFG3, 0,
> + BIT(0));
> + break;
> + default:
> + printf("Unknown PMIC RK%x: Cannot shutdown\n",
> +priv->variant);
> + return -EPROTONOSUPPORT;
> + };
> +
> + return -EINPROGRESS;
> +}
> +
> +static struct sysreset_ops rk8xx_sysreset_ops = {
> + .request= rk8xx_sysreset_request,
> +};
> +
> +U_BOOT_DRIVER(rk8xx_sysreset) = {
> + .name = "rk8xx_sysreset",
> + .id = UCLASS_SYSRESET,
> + .ops= &rk8xx_sysreset_ops,
> +};
>
> static struct reg_data rk817_init_reg[] = {
> /* enable the under-voltage protection,
> @@ -61,7 +101,7 @@ static int rk8xx_read(struct udevice *dev, uint reg,
> uint8_t *buff, int len)
> static int rk8xx_bind(struct udevice *dev)
> {
> ofnode regulators_node;
> - int children;
> + int children, ret;
>
> regulators_node = dev_read_subnode(dev, "regulators");
> if (!ofnode_valid(regulators_node)) {
> @@ -72,6 +112,14 @@ static int rk8xx_bind(struct udevice *dev)
>
> debug("%s: '%s' - found regulators subnode\n", __func__, dev->name);
>
> + if (CONFIG_IS_ENABLED(SYSRESET)) {
> + ret = device_bind_driver_to_node(dev, "rk8xx_sysreset",
> + "rk8xx_sysreset",
> + dev_ofnode(dev), NULL);
> + if (ret)
> + return ret;
> + }
> +
> children = pmic_bind_children(dev, regulators_node, pmic_children_info);
> if (!children)
> debug("%s: %s - no child found\n", __func__, dev->name);
> --
> 2.25.1
>
Re: rk3399 after reboot mmc1 is inaceessible
U-Boot TPL 2022.07-rc6-00020-g049b3b43be-dirty (Jul 09 2022 - 12:52:27) Channel 0: LPDDR4, 50MHz BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB Channel 1: LPDDR4, 50MHz BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB 256B stride lpddr4_set_rate: change freq to 4 mhz 0, 1 lpddr4_set_rate: change freq to 8 mhz 1, 0 Trying to boot from BOOTROM Returning to boot ROM... U-Boot SPL 2022.07-rc6-00020-g049b3b43be-dirty (Jul 09 2022 - 12:52:27 +0200) Trying to boot from MMC2 Buswidth = 0, clock: 0 Buswidth = 1, clock: 0 Buswidth = 1, clock: 40 Sending CMD0 Sending CMD8 Sending CMD55 Sending CMD41 Sending CMD55 Sending CMD41 Sending CMD55 Sending CMD41 Sending CMD55 Sending CMD41 Sending CMD55 Sending CMD41 Sending CMD55 Sending CMD41 Sending CMD2 Sending CMD3 Sending CMD9 Sending CMD7 Sending CMD55 Sending CMD51 Sending CMD6 Sending CMD55 Sending CMD6 Buswidth = 4, clock: 40 Sending CMD6 Buswidth = 4, clock: 2000 Sending CMD16 Sending CMD17 mmc_load_image_raw_sector: mmc block read error Trying to boot from MMC1 Sending CMD16 Sending CMD17 dwmci_data_transfer: Timeout waiting for data! mmc_load_image_raw_sector: mmc block read error Trying to boot from SPI Trying to boot from MMC2 Sending CMD16 Sending CMD17 mmc_load_image_raw_sector: mmc block read error SPL: failed to boot from all boot devices ### ERROR ### Please RESET the board ### On Sun, Jul 03, 2022 at 01:59:15PM +0200, Michal Suchánek wrote: > Hello, > > after rebooting rk3399 Pinebook Pro mmc1 is no longer accessible from > u-boot, and video is not working, only cold boot works. > > This is not a problem anymore when Linux is loaded from another device. > > Any idea how to debug this? > > Thanks > > Michal > > U-Boot TPL 2022.07-rc5 (May 16 2022 - 12:00:00) > Channel 0: LPDDR4, 50MHz > BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB > Channel 1: LPDDR4, 50MHz > BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB > 256B stride > lpddr4_set_rate: change freq to 4 mhz 0, 1 > lpddr4_set_rate: change freq to 8 mhz 1, 0 > Trying to boot from BOOTROM > Returning to boot ROM... > > U-Boot SPL 2022.07-rc5 (May 16 2022 - 12:00:00 +) > Trying to boot from MMC1 > NOTICE: BL31: v2.6(debug): > NOTICE: BL31: Built : 14:50:40, Jul 1 2022 > INFO:GICv3 with legacy support detected. > INFO:ARM GICv3 driver initialized in EL3 > INFO:Maximum SPI INTID supported: 287 > INFO:plat_rockchip_pmu_init(1624): pd status 3e > INFO:BL31: Initializing runtime services > INFO:BL31: cortex_a53: CPU workaround for 855873 was applied > WARNING: BL31: cortex_a53: CPU workaround for 1530924 was missing! > INFO:BL31: Preparing for EL3 exit to normal world > INFO:Entry point address = 0x20 > INFO:SPSR = 0x3c9 > > > U-Boot 2022.07-rc5 (May 16 2022 - 00:00:00 +) > > SoC: Rockchip rk3399 > Reset cause: POR > Model: Pine64 Pinebook Pro > DRAM: 3.9 GiB > PMIC: RK808 > Core: 317 devices, 34 uclasses, devicetree: separate > MMC: mmc@fe31: 3, mmc@fe32: 1, mmc@fe33: 0 > Loading Environment from SPIFlash... SF: Detected gd25q128 with page size 256 > Bytes, erase size 4 KiB, total 16 MiB > *** Warning - bad CRC, using default environment > > In:serial > Out: vidconsole > Err: vidconsole > Model: Pine64 Pinebook Pro > Net: No ethernet found. > starting USB... > Bus usb@fe38: ehci_generic usb@fe38: Failed to get clocks (ret=-19) > Port not available. > Bus usb@fe3a: USB OHCI 1.0 > Bus usb@fe3c: ehci_generic usb@fe3c: Failed to get clocks (ret=-19) > Port not available. > Bus usb@fe3e: USB OHCI 1.0 > Bus usb@fe80: Register 2000140 NbrPorts 2 > Starting the controller > USB XHCI 1.10 > Bus usb@fe90: Register 2000140 NbrPorts 2 > Starting the controller > USB XHCI 1.10 > scanning bus usb@fe3a for devices... 2 USB Device(s) found > scanning bus usb@fe3e for devices... 4 USB Device(s) found > scanning bus usb@fe80 for devices... 1 USB Device(s) found > scanning bus usb@fe90 for devices... 1 USB Device(s) found >scanning usb for storage devices... 1 Storage Device(s) found > Hit any key to stop autoboot: 0 > switch to partitions #0, OK > mmc1 is current device > ** Invalid partition 3 ** > Couldn't find partition mmc 1:3 > ** Invalid partition 4 ** > Couldn't find partition mmc 1:4 > Scanning mmc 1:1... > BootOrder not defined > EFI boot manager: Cannot load any image > Found EFI removable media binary efi/boot/bootaa64.efi > 857968 bytes read in 96 ms (8.5 MiB/s) > Booting /efi\boot\bootaa64.efi > > U-Boot TPL 2022.07-rc5 (May 16 2022 - 12:00:00) > Channel 0: LPD
Re: [PATCH v4 04/21] dm: blk: Add probe in blk_first_device/blk_next_device
On Sun, Oct 02, 2022 at 07:10:40PM -0600, Simon Glass wrote:
> Hi Michal,
>
> On Sun, 2 Oct 2022 at 13:34, Michal Suchánek wrote:
> >
> > On Thu, Sep 29, 2022 at 04:00:26AM -0600, Simon Glass wrote:
> > > Hi Michal,
> > >
> > > On Sun, 25 Sept 2022 at 02:28, Michal Suchanek wrote:
> > > >
> > > > The description claims that the device is probed but it isn't.
> > > >
> > > > Add the device_probe() call.
> > > >
> > > > Also consolidate the iteration into one function.
> > > >
> > > > Fixes: 8a5cbc065d ("dm: blk: Use uclass_find_first/next_device() in
> > > > blk_first/next_device()")
> > > > Signed-off-by: Michal Suchanek
> > > > ---
> > > > drivers/block/blk-uclass.c | 46 ++
> > > > 1 file changed, 22 insertions(+), 24 deletions(-)
> > > >
> > > > diff --git a/drivers/block/blk-uclass.c b/drivers/block/blk-uclass.c
> > > > index 21c5209bb6..992f8ad3da 100644
> > > > --- a/drivers/block/blk-uclass.c
> > > > +++ b/drivers/block/blk-uclass.c
> > > > @@ -361,45 +361,43 @@ int blk_dselect_hwpart(struct blk_desc *desc, int
> > > > hwpart)
> > > > return blk_select_hwpart(desc->bdev, hwpart);
> > > > }
> > > >
> > > > -int blk_first_device(int if_type, struct udevice **devp)
> > > > +static int _blk_next_device(int if_type, struct udevice **devp)
> > > > {
> > > > struct blk_desc *desc;
> > > > - int ret;
> > > > + int ret = 0;
> > > > +
> > > > + for (; *devp; uclass_find_next_device(devp)) {
> > > > + desc = dev_get_uclass_plat(*devp);
> > > > + if (desc->if_type == if_type) {
> > > > + ret = device_probe(*devp);
> > > > + if (!ret)
> > > > + return 0;
> > > > + }
> > > > + }
> > > >
> > > > - ret = uclass_find_first_device(UCLASS_BLK, devp);
> > > > if (ret)
> > > > return ret;
> > > > - if (!*devp)
> > > > - return -ENODEV;
> > > > - do {
> > > > - desc = dev_get_uclass_plat(*devp);
> > > > - if (desc->if_type == if_type)
> > > > - return 0;
> > > > - ret = uclass_find_next_device(devp);
> > > > - if (ret)
> > > > - return ret;
> > > > - } while (*devp);
> > >
> > > This looks wrong since a media device may have other devices under it,
> > > e.g. UCLASS_BOOTDEV so I think you should keep the existing code and
> > > just call uclass_probe() at the end.
> > >
> > > You could add a test for this by checking that only the BLK device is
> > > probed.
> >
> > The description says that it returns ready to use device, and that's not
> > possible when the device is only probed at the end when it is to be
> > returned.
>
> Why is that?
There are two options:
- probe the device, and skip it if it fails, potentially probing
multiple devices before returning one
- decide what device to return, probe it, and if it fails return
non-activated device
> > There are some tests of this function but very few users so it may be OK
> > to change the semantic again to resemble the _check variant uclass
> > iterator and retorn broken devices but I don't think that was the intent
> > here with using uclass_first_device/uclass_next_device originally.
>
> I agree.
>
> >
> > Also this change only makes a difference to the amount of devices probed
> > for callers that only call the blk_first_device and never move on to the
> > next. Callers that use the functions for iteration will move on to the
> > next device and probe it anyway.
>
> OK, perhaps I understand this. But don't you need to update the
> comment in the header file to say that devices that don't probe are
> silently skipped?
They are not ready to use so they cannot be returned by the current
description?
>
> Also it really does need a test.
Right, tests are good to prevent similar regression in the future.
Thanks
Michal
Re: [PATCH v4 04/21] dm: blk: Add probe in blk_first_device/blk_next_device
On Mon, Oct 10, 2022 at 09:49:20PM +0200, Michal Suchánek wrote:
> On Sun, Oct 02, 2022 at 07:10:40PM -0600, Simon Glass wrote:
> > Hi Michal,
> >
> > On Sun, 2 Oct 2022 at 13:34, Michal Suchánek wrote:
> > >
> > > On Thu, Sep 29, 2022 at 04:00:26AM -0600, Simon Glass wrote:
> > > > Hi Michal,
> > > >
> > > > On Sun, 25 Sept 2022 at 02:28, Michal Suchanek
> > > > wrote:
> > > > >
> > > > > The description claims that the device is probed but it isn't.
> > > > >
> > > > > Add the device_probe() call.
> > > > >
> > > > > Also consolidate the iteration into one function.
> > > > >
> > > > > Fixes: 8a5cbc065d ("dm: blk: Use uclass_find_first/next_device() in
> > > > > blk_first/next_device()")
> > > > > Signed-off-by: Michal Suchanek
> > > > > ---
> > > > > drivers/block/blk-uclass.c | 46
> > > > > ++
> > > > > 1 file changed, 22 insertions(+), 24 deletions(-)
> > > > >
> > > > > diff --git a/drivers/block/blk-uclass.c b/drivers/block/blk-uclass.c
> > > > > index 21c5209bb6..992f8ad3da 100644
> > > > > --- a/drivers/block/blk-uclass.c
> > > > > +++ b/drivers/block/blk-uclass.c
> > > > > @@ -361,45 +361,43 @@ int blk_dselect_hwpart(struct blk_desc *desc,
> > > > > int hwpart)
> > > > > return blk_select_hwpart(desc->bdev, hwpart);
> > > > > }
> > > > >
> > > > > -int blk_first_device(int if_type, struct udevice **devp)
> > > > > +static int _blk_next_device(int if_type, struct udevice **devp)
> > > > > {
> > > > > struct blk_desc *desc;
> > > > > - int ret;
> > > > > + int ret = 0;
> > > > > +
> > > > > + for (; *devp; uclass_find_next_device(devp)) {
> > > > > + desc = dev_get_uclass_plat(*devp);
> > > > > + if (desc->if_type == if_type) {
> > > > > + ret = device_probe(*devp);
> > > > > + if (!ret)
> > > > > + return 0;
> > > > > + }
> > > > > + }
> > > > >
> > > > > - ret = uclass_find_first_device(UCLASS_BLK, devp);
> > > > > if (ret)
> > > > > return ret;
> > > > > - if (!*devp)
> > > > > - return -ENODEV;
> > > > > - do {
> > > > > - desc = dev_get_uclass_plat(*devp);
> > > > > - if (desc->if_type == if_type)
> > > > > - return 0;
> > > > > - ret = uclass_find_next_device(devp);
> > > > > - if (ret)
> > > > > - return ret;
> > > > > - } while (*devp);
> > > >
> > > > This looks wrong since a media device may have other devices under it,
> > > > e.g. UCLASS_BOOTDEV so I think you should keep the existing code and
> > > > just call uclass_probe() at the end.
> > > >
> > > > You could add a test for this by checking that only the BLK device is
> > > > probed.
> > >
> > > The description says that it returns ready to use device, and that's not
> > > possible when the device is only probed at the end when it is to be
> > > returned.
> >
> > Why is that?
>
> There are two options:
>
> - probe the device, and skip it if it fails, potentially probing
>multiple devices before returning one
> - decide what device to return, probe it, and if it fails return
>non-activated device
>
> > > There are some tests of this function but very few users so it may be OK
> > > to change the semantic again to resemble the _check variant uclass
> > > iterator and retorn broken devices but I don't think that was the intent
> > > here with using uclass_first_device/uclass_next_device originally.
> >
> > I agree.
> >
> > >
> > > Also this change only makes a difference to the amount of devices probed
> > > for callers that only call the blk_first_device and never move on to the
> > > next. Callers that use the functions for iteration will move on to the
> > > next device and probe it anyway.
> >
> > OK, perhaps I understand this. But don't you need to update the
> > comment in the header file to say that devices that don't probe are
> > silently skipped?
>
> They are not ready to use so they cannot be returned by the current
> description?
>
> >
> > Also it really does need a test.
>
> Right, tests are good to prevent similar regression in the future.
But we don't have the boilerplate for testing failure in block
devices, only in the special probe test class.
Or do we?
Thanks
Michal
Re: [PATCH 1/2] image: Suppress string truncation warning
On Thu, Oct 13, 2022 at 09:29:22AM +0200, Rasmus Villemoes wrote: > On 12/10/2022 21.47, Michal Suchanek wrote: > > In file included from ../tools/imagetool.h:24, > > from ../tools/default_image.c:16: > > In function ‘image_set_name’, > > inlined from ‘image_set_header’ at ../tools/default_image.c:133:2: > > ../include/image.h:786:9: warning: ‘strncpy’ specified bound 32 equals > > destination size [-Wstringop-truncation] > > 786 | strncpy(image_get_name(hdr), name, IH_NMLEN); > > | ^~~~ > > > > There is no standard function that can be used to make the copy without > > a warning. > > True, but the compiler does give a way to inform that the destination is > not _supposed_ to be a nul-terminated string. > > https://lore.kernel.org/u-boot/dad17a9f-d823-1e8b-3381-539612945...@prevas.dk/ > > And our include/linux/compiler_attributes.h indeed already exposes that > __nonstring attribute. Perhaps try applying that to the ih_name member. That's better, that's an actual fix. Thanks Michal
Re: [PATCH v2 1/2] image: Fix string truncation warning
On Thu, Oct 13, 2022 at 10:16:56AM +0200, Michal Suchanek wrote:
> In file included from ../tools/imagetool.h:24,
> from ../tools/default_image.c:16:
> In function ‘image_set_name’,
> inlined from ‘image_set_header’ at ../tools/default_image.c:133:2:
> ../include/image.h:786:9: warning: ‘strncpy’ specified bound 32 equals
> destination size [-Wstringop-truncation]
> 786 | strncpy(image_get_name(hdr), name, IH_NMLEN);
> | ^~~~
Suggested-by: Rasmus Villemoes
> Signed-off-by: Michal Suchanek
> ---
>
> Changes in v2:
> Use __nonstring instead of suppressing the warning
>
> ---
> include/image.h | 3 ++-
> tools/kwbimage.h | 6 --
> 2 files changed, 2 insertions(+), 7 deletions(-)
>
> diff --git a/include/image.h b/include/image.h
> index d7d6a3fe5b..82b447aeb7 100644
> --- a/include/image.h
> +++ b/include/image.h
> @@ -18,6 +18,7 @@
> #include "compiler.h"
> #include
> #include
> +#include
>
> /* Define this to avoid #ifdefs later on */
> struct lmb;
> @@ -275,7 +276,7 @@ struct legacy_img_hdr {
> uint8_t ih_arch;/* CPU architecture */
> uint8_t ih_type;/* Image Type */
> uint8_t ih_comp;/* Compression Type */
> - uint8_t ih_name[IH_NMLEN]; /* Image Name */
> + uint8_t ih_name[IH_NMLEN] __nonstring; /* Image Name */
> };
>
> struct image_info {
> diff --git a/tools/kwbimage.h b/tools/kwbimage.h
> index 505522332b..327ca34494 100644
> --- a/tools/kwbimage.h
> +++ b/tools/kwbimage.h
> @@ -11,12 +11,6 @@
> #include
> #include
>
> -#ifdef __GNUC__
> -#define __packed __attribute((packed))
> -#else
> -#define __packed
> -#endif
> -
> #define KWBIMAGE_MAX_CONFIG ((0x1dc - 0x20)/sizeof(struct reg_config))
> #define MAX_TEMPBUF_LEN 32
>
> --
> 2.37.3
>
Re: [PATCH] sandbox: Eliminate CONFIG_HOST_32/64BIT
Hello, On Fri, Oct 14, 2022 at 08:40:52AM +0200, Heinrich Schuchardt wrote: > From: Heinrich Schuchardt > > Building sandbox_defconfig on 32bit systems requires manual configuration. > we should void this. > > The compiler provides symbol __LP64__. This is enough to know if the host > is a 64bit or a 32bit system. > > Reported-by: Michal Suchanek > Signed-off-by: Heinrich Schuchardt > --- > arch/sandbox/Kconfig | 24 > arch/sandbox/include/asm/posix_types.h | 8 +++- > drivers/misc/swap_case.c | 2 +- > include/linux/bitops.h | 2 +- > 4 files changed, 9 insertions(+), 27 deletions(-) > > diff --git a/arch/sandbox/Kconfig b/arch/sandbox/Kconfig > index 852a7c8bf2..c7668233b9 100644 > --- a/arch/sandbox/Kconfig > +++ b/arch/sandbox/Kconfig > @@ -13,7 +13,6 @@ config SYS_CPU > config SANDBOX64 > bool "Use 64-bit addresses" > select PHYS_64BIT > - select HOST_64BIT eliminating the Kconfig option makes it no longer possible SANDBOX64 depend on building 64bit. Thanks Michal > > config SANDBOX_RAM_SIZE_MB > int "RAM size in MiB" > @@ -41,24 +40,6 @@ config SYS_CONFIG_NAME > default "sandbox_spl" if SANDBOX_SPL > default "sandbox" if !SANDBOX_SPL > > -choice > - prompt "Run sandbox on 32/64-bit host" > - default HOST_64BIT > - help > - Sandbox can be built on 32-bit and 64-bit hosts. > - The default is to build on a 64-bit host and run > - on a 64-bit host. If you want to run sandbox on > - a 32-bit host, change it here. > - > -config HOST_32BIT > - bool "32-bit host" > - depends on !PHYS_64BIT > - > -config HOST_64BIT > - bool "64-bit host" > - > -endchoice > - > config SANDBOX_CRASH_RESET > bool "Reset on crash" > help > @@ -68,11 +49,6 @@ config SANDBOX_CRASH_RESET > test suites like the UEFI self certification test which continue > with the next test after a crash. > > -config SANDBOX_BITS_PER_LONG > - int > - default 32 if HOST_32BIT > - default 64 if HOST_64BIT > - > config SYS_FDT_LOAD_ADDR > hex "Address at which to load devicetree" > default 0x100 > diff --git a/arch/sandbox/include/asm/posix_types.h > b/arch/sandbox/include/asm/posix_types.h > index ec18ed7e3c..0129e91122 100644 > --- a/arch/sandbox/include/asm/posix_types.h > +++ b/arch/sandbox/include/asm/posix_types.h > @@ -19,6 +19,12 @@ > * assume GCC is being used. > */ > > +#ifdef __LP64__ > +#define SANDBOX_BITS_PER_LONG 64 > +#else > +#define SANDBOX_BITS_PER_LONG 32 > +#endif > + > typedef unsigned short __kernel_dev_t; > typedef unsigned long__kernel_ino_t; > typedef unsigned short __kernel_mode_t; > @@ -28,7 +34,7 @@ typedef int __kernel_pid_t; > typedef unsigned short __kernel_ipc_pid_t; > typedef unsigned short __kernel_uid_t; > typedef unsigned short __kernel_gid_t; > -#if CONFIG_SANDBOX_BITS_PER_LONG == 32 > +#if SANDBOX_BITS_PER_LONG == 32 > typedef unsigned int __kernel_size_t; > typedef int __kernel_ssize_t; > typedef int __kernel_ptrdiff_t; > diff --git a/drivers/misc/swap_case.c b/drivers/misc/swap_case.c > index 7093ad1cd4..205ed81750 100644 > --- a/drivers/misc/swap_case.c > +++ b/drivers/misc/swap_case.c > @@ -331,7 +331,7 @@ static int sandbox_swap_case_map_physmem(struct udevice > *dev, > *ptrp = &pci_ea_bar2_magic; > *lenp = PCI_CAP_EA_SIZE_LO; > break; > -#ifdef CONFIG_HOST_64BIT > +#ifdef __LP64__ > /* >* This cannot be work on a 32-bit machine since *lenp is ulong >* which is 32-bits, but it needs to have a 64-bit value > diff --git a/include/linux/bitops.h b/include/linux/bitops.h > index d2e5ca026e..6456f5ad45 100644 > --- a/include/linux/bitops.h > +++ b/include/linux/bitops.h > @@ -28,7 +28,7 @@ > */ > #ifdef CONFIG_SANDBOX > #define GENMASK(h, l) \ > - (((~0UL) << (l)) & (~0UL >> (CONFIG_SANDBOX_BITS_PER_LONG - 1 - (h > + (((~0UL) << (l)) & (~0UL >> (SANDBOX_BITS_PER_LONG - 1 - (h > #else > #define GENMASK(h, l) \ > (((~0UL) << (l)) & (~0UL >> (BITS_PER_LONG - 1 - (h > -- > 2.37.2 >
Re: [PATCH] tests: Build correct sandbox configuration on 32bit
On Fri, Oct 14, 2022 at 05:05:26AM +0200, Heinrich Schuchardt wrote: > On 10/13/22 22:28, Michal Suchanek wrote: > > Currently sandbox configuration defautls to 64bit and there is no > > automation for building 32bit sandbox on 32bit hosts. > > > > cpp does not know about target specification, code needs to be compiled > > to determine integer width. > > > > Add a test program that prints the integer width, and a make target that > > aligns the sandbox configuration with the result. > > > > Signed-off-by: Michal Suchanek > > --- > > > > Makefile | 6 ++ > > doc/arch/sandbox.rst | 16 +++- > > test/py/conftest.py | 1 + > > tools/Makefile| 2 ++ > > tools/bits-per-long.c | 14 ++ > > 5 files changed, 34 insertions(+), 5 deletions(-) > > create mode 100644 tools/bits-per-long.c > > > > diff --git a/Makefile b/Makefile > > index 3866cc62f9..e5463573f3 100644 > > --- a/Makefile > > +++ b/Makefile > > @@ -2166,6 +2166,12 @@ tools-all: envtools tools ; > > cross_tools: export CROSS_BUILD_TOOLS=y > > cross_tools: tools ; > > > > +PHONY += set_host_bits > > +set_host_bits: tools > > + $(Q)sed -i -e /CONFIG_HOST_$$($(objtree)/tools/bits-per-long)BIT/d > > $(KCONFIG_CONFIG) > > + $(Q)sed -i -E -e "s/CONFIG_HOST_(..)BIT=y/# CONFIG_HOST_\1BIT is not > > set/" $(KCONFIG_CONFIG) > > + $(Q)echo CONFIG_HOST_$$($(objtree)/tools/bits-per-long)BIT=y >> > > $(KCONFIG_CONFIG) > > + > > .PHONY : CHANGELOG > > CHANGELOG: > > git log --no-merges U-Boot-1_1_5.. | \ > > diff --git a/doc/arch/sandbox.rst b/doc/arch/sandbox.rst > > index 068d4a3be4..d751205eba 100644 > > --- a/doc/arch/sandbox.rst > > +++ b/doc/arch/sandbox.rst > > @@ -33,9 +33,11 @@ machines. > > > > There are two versions of the sandbox: One using 32-bit-wide integers, > > and one > > using 64-bit-wide integers. The 32-bit version can be build and run on > > either > > -32 or 64-bit hosts by either selecting or deselecting > > CONFIG_SANDBOX_32BIT; by > > -default, the sandbox it built for a 32-bit host. The sandbox using > > 64-bit-wide > > -integers can only be built on 64-bit hosts. > > +32 or 64-bit hosts by either selecting or deselecting HOST_64BIT; by > > +default, the sandbox it built for a 64-bit host. The sandbox using > > 64-bit-wide > > +integers can only be built on 64-bit hosts. There is no automation for > > ensuring > > +32bit build on 32bit hosts - use ``make set_host_bits`` to adjust the > > sandbox > > +config. > > > > Note that standalone/API support is not available at present. > > > > @@ -51,7 +53,9 @@ Basic Operation > > > > To run sandbox U-Boot use something like:: > > > > - make sandbox_defconfig all > > + make sandbox_defconfig > > + make set_host_bits > > + make all > > Thanks for addressing the problem of sandbox bitness. > > We should not make building the sandbox more complicated. You could > integrate building set_host_bits into an existing target like u-boot.cfg:. > > Overall an approach with an external program is too complicated. > CONFIG_HOST_32BIT and CONFIG_HOST_64BIT are used to define > CONFIG_SANDBOX_BITS_PER_LONG. And for making SANDBOX64 depend on 64bit build. > > We could add > > #ifndef __LP64__ > #undef SANDBOX_BITS_PER_LONG > #define SANDBOX_BITS_PER_LONG 32 > #endif If we are willing to depend on this define which is clearly named as compiler-internal we could do similar to cc-option to run something like $(CC) -dM -E - < /dev/null | grep -q _LP64 > > to the top of arch/sandbox/include/asm/posix_types.h and use > > #if defined(CONFIG_HOST_64BIT) && defined(__LP64__) > > in drivers/misc/swap_case.c to solve the problem. This demonstrates that > CONFIG_HOST_32BIT and CONFIG_HOST_64BIT are superfluous symbols. Not really. Thanks Michal
Re: [PATCH] sandbox: Eliminate CONFIG_HOST_32/64BIT
On Fri, Oct 14, 2022 at 01:33:33PM +0200, Heinrich Schuchardt wrote: > On 10/14/22 10:33, Michal Suchánek wrote: > > Hello, > > > > On Fri, Oct 14, 2022 at 08:40:52AM +0200, Heinrich Schuchardt wrote: > > > From: Heinrich Schuchardt > > > > > > Building sandbox_defconfig on 32bit systems requires manual configuration. > > > we should void this. > > > > > > The compiler provides symbol __LP64__. This is enough to know if the host > > > is a 64bit or a 32bit system. > > > > > > Reported-by: Michal Suchanek > > > Signed-off-by: Heinrich Schuchardt > > > --- > > > arch/sandbox/Kconfig | 24 > > > arch/sandbox/include/asm/posix_types.h | 8 +++- > > > drivers/misc/swap_case.c | 2 +- > > > include/linux/bitops.h | 2 +- > > > 4 files changed, 9 insertions(+), 27 deletions(-) > > > > > > diff --git a/arch/sandbox/Kconfig b/arch/sandbox/Kconfig > > > index 852a7c8bf2..c7668233b9 100644 > > > --- a/arch/sandbox/Kconfig > > > +++ b/arch/sandbox/Kconfig > > > @@ -13,7 +13,6 @@ config SYS_CPU > > > config SANDBOX64 > > > bool "Use 64-bit addresses" > > > select PHYS_64BIT > > > - select HOST_64BIT > > > > eliminating the Kconfig option makes it no longer possible SANDBOX64 > > depend on building 64bit. > > Looking at include/linux/bitops.h and drivers/misc/swap_case.c it was always > wrong to use HOST_64BIT=y when building sandbox64_defconfig on an ILP32 > system. And it will continue to be wrong when there is no config option that SANDBOX64 can depend on so it cannot be enabled on 32bit. Thanks Michal > > Best regards > > Heinrich > > > > > Thanks > > > > Michal > > > config SANDBOX_RAM_SIZE_MB > > > int "RAM size in MiB" > > > @@ -41,24 +40,6 @@ config SYS_CONFIG_NAME > > > default "sandbox_spl" if SANDBOX_SPL > > > default "sandbox" if !SANDBOX_SPL > > > -choice > > > - prompt "Run sandbox on 32/64-bit host" > > > - default HOST_64BIT > > > - help > > > - Sandbox can be built on 32-bit and 64-bit hosts. > > > - The default is to build on a 64-bit host and run > > > - on a 64-bit host. If you want to run sandbox on > > > - a 32-bit host, change it here. > > > - > > > -config HOST_32BIT > > > - bool "32-bit host" > > > - depends on !PHYS_64BIT > > > - > > > -config HOST_64BIT > > > - bool "64-bit host" > > > - > > > -endchoice > > > - > > > config SANDBOX_CRASH_RESET > > > bool "Reset on crash" > > > help > > > @@ -68,11 +49,6 @@ config SANDBOX_CRASH_RESET > > > test suites like the UEFI self certification test which > > > continue > > > with the next test after a crash. > > > -config SANDBOX_BITS_PER_LONG > > > - int > > > - default 32 if HOST_32BIT > > > - default 64 if HOST_64BIT > > > - > > > config SYS_FDT_LOAD_ADDR > > > hex "Address at which to load devicetree" > > > default 0x100 > > > diff --git a/arch/sandbox/include/asm/posix_types.h > > > b/arch/sandbox/include/asm/posix_types.h > > > index ec18ed7e3c..0129e91122 100644 > > > --- a/arch/sandbox/include/asm/posix_types.h > > > +++ b/arch/sandbox/include/asm/posix_types.h > > > @@ -19,6 +19,12 @@ > > >* assume GCC is being used. > > >*/ > > > +#ifdef __LP64__ > > > +#define SANDBOX_BITS_PER_LONG 64 > > > +#else > > > +#define SANDBOX_BITS_PER_LONG 32 > > > +#endif > > > + > > > typedef unsigned short __kernel_dev_t; > > > typedef unsigned long __kernel_ino_t; > > > typedef unsigned short __kernel_mode_t; > > > @@ -28,7 +34,7 @@ typedef int __kernel_pid_t; > > > typedef unsigned short __kernel_ipc_pid_t; > > > typedef unsigned short __kernel_uid_t; > > > typedef unsigned short __kernel_gid_t; > > > -#if CONFIG_SANDBOX_BITS_PER_LONG == 32 > > > +#if SANDBOX_BITS_PER_LONG == 32 > > > typedef unsigned int__kernel_size_t; > > > typedef int
Re: [PATCH v2] tests: Build correct sandbox configuration on 32bit
On Sat, Oct 15, 2022 at 06:54:02AM +0200, Heinrich Schuchardt wrote: > On 10/14/22 22:52, Michal Suchanek wrote: > > Currently sandbox configuration defautls to 64bit and there is no > > automation for building 32bit sandbox on 32bit hosts. > > > > Use _LP64 macro as heuristic for detecting 64bit targets. > > > > Signed-off-by: Michal Suchanek > > Please, explain why you think a Kconfig level patch is preferable to > what I proposed in > > [PATCH] sandbox: Eliminate CONFIG_HOST_32/64BIT > https://lists.denx.de/pipermail/u-boot/2022-October/497236.html The existing dependency canot be described when the option is eliminated: > config SANDBOX64 > bool "Use 64-bit addresses" > select PHYS_64BIT > - select HOST_64BIT > + depends on HOST_64BIT If we can run SANDBOX64 on 32bit eliminating the option is fine. Thanks Michal > > > --- > > > > Changes in v2: > > simplify and move detection to kconfig > > > > --- > > arch/sandbox/Kconfig| 18 +++--- > > scripts/Kconfig.include | 4 > > 2 files changed, 7 insertions(+), 15 deletions(-) > > > > diff --git a/arch/sandbox/Kconfig b/arch/sandbox/Kconfig > > index 852a7c8bf2..35508c6b29 100644 > > --- a/arch/sandbox/Kconfig > > +++ b/arch/sandbox/Kconfig > > @@ -13,7 +13,7 @@ config SYS_CPU > > config SANDBOX64 > > bool "Use 64-bit addresses" > > select PHYS_64BIT > > - select HOST_64BIT > > + depends on HOST_64BIT > > > > config SANDBOX_RAM_SIZE_MB > > int "RAM size in MiB" > > @@ -41,23 +41,11 @@ config SYS_CONFIG_NAME > > default "sandbox_spl" if SANDBOX_SPL > > default "sandbox" if !SANDBOX_SPL > > > > -choice > > - prompt "Run sandbox on 32/64-bit host" > > - default HOST_64BIT > > - help > > - Sandbox can be built on 32-bit and 64-bit hosts. > > - The default is to build on a 64-bit host and run > > - on a 64-bit host. If you want to run sandbox on > > - a 32-bit host, change it here. > > - > > config HOST_32BIT > > - bool "32-bit host" > > - depends on !PHYS_64BIT > > + def_bool ! $(cc-define,_LP64) > > > > config HOST_64BIT > > - bool "64-bit host" > > - > > -endchoice > > + def_bool $(cc-define,_LP64) > > > > config SANDBOX_CRASH_RESET > > bool "Reset on crash" > > diff --git a/scripts/Kconfig.include b/scripts/Kconfig.include > > index dad5583451..b7598ca5d9 100644 > > --- a/scripts/Kconfig.include > > +++ b/scripts/Kconfig.include > > This include is copied from Linux. From time to time we synchronize the > Kconfig framework from Linux. So we should avoid U-Boot specific changes > here. > > Best regards > > Heinrich > > > @@ -22,6 +22,10 @@ success = $(if-success,$(1),y,n) > > # Return y if the compiler supports , n otherwise > > cc-option = $(success,$(CC) -Werror $(1) -E -x c /dev/null -o /dev/null) > > > > +# $(cc-define,) > > +# Return y if the compiler defines , n otherwise > > +cc-define = $(success,$(CC) -dM -E -x c /dev/null | grep -q '^#define > > \<$(1)\>') > > + > > # $(ld-option,) > > # Return y if the linker supports , n otherwise > > ld-option = $(success,$(LD) -v $(1)) >
Re: [PATCH 1/1] sandbox: make sandbox system reset configurable
Hello, On Sat, Oct 15, 2022 at 10:39:19AM +0200, Heinrich Schuchardt wrote: > To test the watchdog system reset we need to disable the default sandbox > system reset. > > The following settings provide the reset command via watchdog on the > sandbox: > > CONFIG_WDT_GPIO=n > CONFIG_WDT_SANDBOX=y > CONFIG_SYSRESET_SANDBOX=n > CONFIG_SYSRESET_WATCHDOG=y > CONFIG_SYSRESET_WATCHDOG_AUTO=y Woudn't it be better to make this runtime configurable? Thanks Michal > > Signed-off-by: Heinrich Schuchardt > --- > drivers/sysreset/Kconfig | 7 +++ > drivers/sysreset/Makefile | 2 +- > 2 files changed, 8 insertions(+), 1 deletion(-) > > diff --git a/drivers/sysreset/Kconfig b/drivers/sysreset/Kconfig > index 03f7fdd597..3bd38fc585 100644 > --- a/drivers/sysreset/Kconfig > +++ b/drivers/sysreset/Kconfig > @@ -110,6 +110,13 @@ config SYSRESET_PSCI > Enable PSCI SYSTEM_RESET function call. To use this, PSCI firmware > must be running on your system. > > +config SYSRESET_SANDBOX > + bool "Enable support for Sandbox System Reset" > + depends on SANDBOX > + default y > + help > + Enable sandbox system reset implementation. > + > config SYSRESET_SBI > bool "Enable support for SBI System Reset" > depends on RISCV_SMODE && SBI_V02 > diff --git a/drivers/sysreset/Makefile b/drivers/sysreset/Makefile > index 0ed3bbf356..d4b6e575be 100644 > --- a/drivers/sysreset/Makefile > +++ b/drivers/sysreset/Makefile > @@ -6,7 +6,7 @@ obj-$(CONFIG_$(SPL_TPL_)SYSRESET) += sysreset-uclass.o > obj-$(CONFIG_ARCH_ASPEED) += sysreset_ast.o > obj-$(CONFIG_ARCH_ROCKCHIP) += sysreset_rockchip.o > obj-$(CONFIG_ARCH_STI) += sysreset_sti.o > -obj-$(CONFIG_SANDBOX) += sysreset_sandbox.o > +obj-$(CONFIG_SYSRESET_SANDBOX) += sysreset_sandbox.o > obj-$(CONFIG_POWEROFF_GPIO) += poweroff_gpio.o > obj-$(CONFIG_SYSRESET_GPIO) += sysreset_gpio.o > obj-$(CONFIG_SYSRESET_MPC83XX) += sysreset_mpc83xx.o > -- > 2.37.2 >
Re: [PATCH v2] tests: Build correct sandbox configuration on 32bit
On Sat, Oct 15, 2022 at 09:05:53PM +0200, Heinrich Schuchardt wrote: > On 10/15/22 20:39, Simon Glass wrote: > > Hi Heinrich, > > > > On Sat, 15 Oct 2022 at 12:31, Heinrich Schuchardt > > wrote: > > > > > > On 10/15/22 19:53, Simon Glass wrote: > > > > Hi Michal, > > > > > > > > On Fri, 14 Oct 2022 at 14:53, Michal Suchanek wrote: > > > > > > > > > > Currently sandbox configuration defautls to 64bit and there is no > > > > > automation for building 32bit sandbox on 32bit hosts. > > > > > > > > > > Use _LP64 macro as heuristic for detecting 64bit targets. > > > > > > > > > > Signed-off-by: Michal Suchanek > > > > > --- > > > > > > > > > > Changes in v2: > > > > > simplify and move detection to kconfig > > > > > > > > > > --- > > > > >arch/sandbox/Kconfig| 18 +++--- > > > > >scripts/Kconfig.include | 4 > > > > >2 files changed, 7 insertions(+), 15 deletions(-) > > > > > > > > Reviewed-by: Simon Glass > > > > > > > > My only question is whether we can allow building the 32-bit version > > > > on a 64-bit machine? That would need a separate option I think, to > > > > say: > > > > > > > > I don't want you to automatically determine HOST_32/64BIT. Instead, > > > > use 32 (or 64). > > > > > > > > This is along the lines of what Heinrich is saying, except that I > > > > strongly feel that we must do the right thing by default, as your > > > > patch does. > > > > > > The whole point of phys_addr_t and phys_size_t is that it can be 64bit > > > or 32bit on ilp32. > > > > > > With this patch we cannot build with CONFIG_PHYS_64BIT=y on ilp32 and > > > that is bad. > > > > > > 32 bit phys_addr_t on lp64 is irrelevant for actual hardware but this is > > > what we currently test with sandbox_defconfig on Gitlab CI. > > > > > > My patch is ending up in the same behavior as Michal's patch except that > > > it allows to have 64bit phys_addr_t on ilp32. > > > > It needs to automatically default to 32 or 64 bit depending on the > > host. If the user wants to fiddle with Kconfig to force it to the > > other one, that should be possible to. > > > > It looks like your patch requires manual configuration, but perhaps I > > just misunderstood it? > > __LP64__ is a symbol defined by the compiler when compiling for 64bit > and not defined when compiling for 32bit systems. There is nothing > manual about it. > > My patch uses this symbol to replace HOST_32BIT and HOST_64BIT. > > Michal's patch compiles a program tools/bits-per-long.c that ends up > returning 64 on 64 bit systems (where __LP64__ is defined) and 32 on 32 > bit systems (where __LP64__ is not defined) and then chooses HOST_32BIT > and HOST_64BIT accordingly. This part of Michal's patch is not wrong. > The solution is only overly complicated. > > What has to be chosen manually with both patches is PHYS_64BIT e.g. by > selecting sandbox64_defconfig instead of sandbox_defconfig. > > Unfortunately Michal did not understand that PHYS_64BIT=y, HOST_32BIT=y > is a necessary test scenario and introduced an invalid dependency. It did not introduce it, it merely did not remove it. > With my patch sandbox64_defconfig on a 32bit system uses 64bit phys_addr_t. > > With Michal's patch sandbox64_defconfig on a 32bit system uses 32bit > phys_addr_t. > > Best regards > > Heinrich
Re: [PATCH] clk: k210: Fix error calculation on 32bit
On Thu, Oct 13, 2022 at 10:34:29PM +0200, Michal Suchanek wrote:
> k210 is 64bit but the driver and tests are also built in sandbox, and
> that can be built 32bit.
>
> BIT(32) does not work on 32bit, shift before subtraction to fit into
> 32bit integer with BIT values.
Also see
https://patchwork.ozlabs.org/project/uboot/patch/20221016071035.461454-1-heinrich.schucha...@canonical.com/
>
> Signed-off-by: Michal Suchanek
> ---
>
> drivers/clk/clk_k210.c | 2 +-
> test/dm/k210_pll.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/clk/clk_k210.c b/drivers/clk/clk_k210.c
> index 1961efaa5e..e85f8ae14a 100644
> --- a/drivers/clk/clk_k210.c
> +++ b/drivers/clk/clk_k210.c
> @@ -846,7 +846,7 @@ again:
>
> error = DIV_ROUND_CLOSEST_ULL(f * inv_ratio, r * od);
> /* The lower 16 bits are spurious */
> - error = abs((error - BIT(32))) >> 16;
> + error = abs((error >> 16) - BIT(32 - 16));
>
> if (error < best_error) {
> best->r = r;
> diff --git a/test/dm/k210_pll.c b/test/dm/k210_pll.c
> index a0cc84c396..622b1c9bef 100644
> --- a/test/dm/k210_pll.c
> +++ b/test/dm/k210_pll.c
> @@ -33,7 +33,7 @@ static int dm_test_k210_pll_calc_config(u32 rate, u32
> rate_in,
> error = DIV_ROUND_CLOSEST_ULL(f * inv_ratio,
> r * od);
> /* The lower 16 bits are spurious */
> - error = abs((error - BIT(32))) >> 16;
> + error = abs((error >> 16) - BIT(32 - 16));
> if (error < best_error) {
> best->r = r;
> best->f = f;
> --
> 2.37.3
>
Re: [PATCH] clk: k210: Fix error calculation on 32bit
Hello, On Sun, Oct 16, 2022 at 05:02:38PM +0200, Heinrich Schuchardt wrote: > > > On 10/16/22 16:57, Sean Anderson wrote: > > On 10/16/22 10:50, Heinrich Schuchardt wrote: > > > > > > > > > On 10/16/22 16:48, Sean Anderson wrote: > > > > On 10/16/22 10:40, Heinrich Schuchardt wrote: > > > > > > > > > > > > > > > On 10/16/22 16:19, Sean Anderson wrote: > > > > > > On 10/16/22 07:46, Heinrich Schuchardt wrote: > > > > > > > > > > > > > > > > > > > > > On 10/16/22 09:51, Michal Suchánek wrote: > > > > > > > > On Thu, Oct 13, 2022 at 10:34:29PM +0200, Michal Suchanek wrote: > > > > > > > > > k210 is 64bit but the driver and tests are > > > > > > > > > also built in sandbox, and > > > > > > > > > that can be built 32bit. > > > > > > > > > > > > > > > > > > BIT(32) does not work on 32bit, shift before > > > > > > > > > subtraction to fit into > > > > > > > > > 32bit integer with BIT values. > > > > > > > > > > > > IMO the driver should just be changed to depend on > > > > > > 64-bit. The k210 is 64-bit, > > > > > > and I didn't write anything with 32-bit in mind. > > > > > > > > > > Michal, Simon, and I are striving to get the sandbox working > > > > > on ilp32 systems. > > > > > > > > > > Do you suggest to remove the driver from sandbox_defconfig? > > > > > > > > > > This would imply that the unit test is not executed on > > > > > Gitlab CI. You will still be able to execute it on the > > > > > actual hardware. > > > > > > > > It's still enabled for sandbox64, so it should still be executed there. > > > > > > No, the sandbox64 is also to be compiled on ilp32. It models > > > physical address extension (PAE). > > > > Do we have a config for word size? PHYS_64BIT seems to be for the > > address size. > > phys_addr_t is what is used to address physical memory which may be 64bit on > a 32bit PAE system (CONFIG_PHYS_64BIT=y). > > Compiling on armv7 yields 32bit pointers. > > There are two alternative patches in review removing HOST_32BIT and > HOST_64BIT: > > https://patchwork.ozlabs.org/project/uboot/patch/20221014064052.5592-1-heinrich.schucha...@canonical.com/ > > https://patchwork.ozlabs.org/project/uboot/patch/20221013203429.15200-1-msucha...@suse.de/ I don't think that we have a config option that can be used to detect that the build is 64bit. Such option may exit per platform but drivers that can be built for multiple platforms will have hard time detecting it. I think that Heinrich's suggestion to use BIT_ULL instead of BIT and abs64 instead of abs is non-controversial. It's technically more correct way to write the expression although relevant only for 32bit. Thanks Michal
Re: [PATCH v2] tests: Build correct sandbox configuration on 32bit
On Sat, Oct 15, 2022 at 10:27:43PM +0200, Heinrich Schuchardt wrote: > On 10/15/22 21:46, Simon Glass wrote: > > Hi Heinrich, > > > > On Sat, 15 Oct 2022 at 13:29, Heinrich Schuchardt > > wrote: > > > > > > > > > > > > Am 15. Oktober 2022 21:24:36 MESZ schrieb Simon Glass : > > > > Hi Heinrich, > > > > > > > > On Sat, 15 Oct 2022 at 13:05, Heinrich Schuchardt > > > > wrote: > > > > > > > > > > On 10/15/22 20:39, Simon Glass wrote: > > > > > > Hi Heinrich, > > > > > > > > > > > > On Sat, 15 Oct 2022 at 12:31, Heinrich Schuchardt > > > > > > wrote: > > > > > > > > > > > > > > On 10/15/22 19:53, Simon Glass wrote: > > > > > > > > Hi Michal, > > > > > > > > > > > > > > > > On Fri, 14 Oct 2022 at 14:53, Michal Suchanek > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > Currently sandbox configuration defautls to 64bit and there > > > > > > > > > is no > > > > > > > > > automation for building 32bit sandbox on 32bit hosts. > > > > > > > > > > > > > > > > > > Use _LP64 macro as heuristic for detecting 64bit targets. > > > > > > > > > > > > > > > > > > Signed-off-by: Michal Suchanek > > > > > > > > > --- > > > > > > > > > > > > > > > > > > Changes in v2: > > > > > > > > > simplify and move detection to kconfig > > > > > > > > > > > > > > > > > > --- > > > > > > > > > arch/sandbox/Kconfig| 18 +++--- > > > > > > > > > scripts/Kconfig.include | 4 > > > > > > > > > 2 files changed, 7 insertions(+), 15 deletions(-) > > > > > > > > > > > > > > > > Reviewed-by: Simon Glass > > > > > > > > > > > > > > > > My only question is whether we can allow building the 32-bit > > > > > > > > version > > > > > > > > on a 64-bit machine? That would need a separate option I think, > > > > > > > > to > > > > > > > > say: > > > > > > > > > > > > > > > > I don't want you to automatically determine HOST_32/64BIT. > > > > > > > > Instead, > > > > > > > > use 32 (or 64). > > > > > > > > > > > > > > > > This is along the lines of what Heinrich is saying, except that > > > > > > > > I > > > > > > > > strongly feel that we must do the right thing by default, as > > > > > > > > your > > > > > > > > patch does. > > > > > > > > > > > > > > The whole point of phys_addr_t and phys_size_t is that it can be > > > > > > > 64bit > > > > > > > or 32bit on ilp32. > > > > > > > > > > > > > > With this patch we cannot build with CONFIG_PHYS_64BIT=y on ilp32 > > > > > > > and > > > > > > > that is bad. > > > > > > > > > > > > > > 32 bit phys_addr_t on lp64 is irrelevant for actual hardware but > > > > > > > this is > > > > > > > what we currently test with sandbox_defconfig on Gitlab CI. > > > > > > > > > > > > > > My patch is ending up in the same behavior as Michal's patch > > > > > > > except that > > > > > > > it allows to have 64bit phys_addr_t on ilp32. > > > > > > > > > > > > It needs to automatically default to 32 or 64 bit depending on the > > > > > > host. If the user wants to fiddle with Kconfig to force it to the > > > > > > other one, that should be possible to. > > > > > > > > > > > > It looks like your patch requires manual configuration, but perhaps > > > > > > I > > > > > > just misunderstood it? > > > > > > > > > > __LP64__ is a symbol defined by the compiler when compiling for 64bit > > > > > and not defined when compiling for 32bit systems. There is nothing > > > > > manual about it. > > > > > > > > > > My patch uses this symbol to replace HOST_32BIT and HOST_64BIT. > > > > > > > > > > Michal's patch compiles a program tools/bits-per-long.c that ends up > > > > > returning 64 on 64 bit systems (where __LP64__ is defined) and 32 on > > > > > 32 > > > > > bit systems (where __LP64__ is not defined) and then chooses > > > > > HOST_32BIT > > > > > and HOST_64BIT accordingly. This part of Michal's patch is not wrong. > > > > > The solution is only overly complicated. > > > > > > > > > > What has to be chosen manually with both patches is PHYS_64BIT e.g. by > > > > > selecting sandbox64_defconfig instead of sandbox_defconfig. > > > > > > > > > > Unfortunately Michal did not understand that PHYS_64BIT=y, > > > > > HOST_32BIT=y > > > > > is a necessary test scenario and introduced an invalid dependency. > > > > > > > > > > With my patch sandbox64_defconfig on a 32bit system uses 64bit > > > > > phys_addr_t. > > > > > > > > > > With Michal's patch sandbox64_defconfig on a 32bit system uses 32bit > > > > > phys_addr_t. > > > > > > > > That's all great, thank you, but please can you address my actual > > > > question? > > > > > > Your question in this thread was if my patch requires extra manual > > > configuration compared to Michal's patch and the answer was no. > > > > > > What other question do you have? > > > > "It needs to automatically default to 32 or 64 bit depending on the > > host. If the user wants to fiddle with Kconfig to force it to the > > other one, that should be possible to." > > The user forces 32bit or 64bit by selecting a 32
Re: [PATCH v2] tests: Build correct sandbox configuration on 32bit
On Fri, Oct 21, 2022 at 06:05:51PM -0700, Simon Glass wrote: > Hi, > > On Mon, 17 Oct 2022 at 01:28, Michal Suchánek wrote: > > > > On Sat, Oct 15, 2022 at 10:27:43PM +0200, Heinrich Schuchardt wrote: > > > On 10/15/22 21:46, Simon Glass wrote: > > > > Hi Heinrich, > > > > > > > > On Sat, 15 Oct 2022 at 13:29, Heinrich Schuchardt > > > > wrote: > > > > > > > > > > > > > > > > > > > > Am 15. Oktober 2022 21:24:36 MESZ schrieb Simon Glass > > > > > : > > > > > > Hi Heinrich, > > > > > > > > > > > > On Sat, 15 Oct 2022 at 13:05, Heinrich Schuchardt > > > > > > wrote: > > > > > > > > > > > > > > On 10/15/22 20:39, Simon Glass wrote: > > > > > > > > Hi Heinrich, > > > > > > > > > > > > > > > > On Sat, 15 Oct 2022 at 12:31, Heinrich Schuchardt > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > On 10/15/22 19:53, Simon Glass wrote: > > > > > > > > > > Hi Michal, > > > > > > > > > > > > > > > > > > > > On Fri, 14 Oct 2022 at 14:53, Michal Suchanek > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > Currently sandbox configuration defautls to 64bit and > > > > > > > > > > > there is no > > > > > > > > > > > automation for building 32bit sandbox on 32bit hosts. > > > > > > > > > > > > > > > > > > > > > > Use _LP64 macro as heuristic for detecting 64bit targets. > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Michal Suchanek > > > > > > > > > > > --- > > > > > > > > > > > > > > > > > > > > > > Changes in v2: > > > > > > > > > > > simplify and move detection to kconfig > > > > > > > > > > > > > > > > > > > > > > --- > > > > > > > > > > > arch/sandbox/Kconfig| 18 +++--- > > > > > > > > > > > scripts/Kconfig.include | 4 > > > > > > > > > > > 2 files changed, 7 insertions(+), 15 deletions(-) > > > > > > > > > > > > > > > > > > > > Reviewed-by: Simon Glass > > > > > > > > > > > > > > > > > > > > My only question is whether we can allow building the > > > > > > > > > > 32-bit version > > > > > > > > > > on a 64-bit machine? That would need a separate option I > > > > > > > > > > think, to > > > > > > > > > > say: > > > > > > > > > > > > > > > > > > > > I don't want you to automatically determine HOST_32/64BIT. > > > > > > > > > > Instead, > > > > > > > > > > use 32 (or 64). > > > > > > > > > > > > > > > > > > > > This is along the lines of what Heinrich is saying, except > > > > > > > > > > that I > > > > > > > > > > strongly feel that we must do the right thing by default, > > > > > > > > > > as your > > > > > > > > > > patch does. > > > > > > > > > > > > > > > > > > The whole point of phys_addr_t and phys_size_t is that it can > > > > > > > > > be 64bit > > > > > > > > > or 32bit on ilp32. > > > > > > > > > > > > > > > > > > With this patch we cannot build with CONFIG_PHYS_64BIT=y on > > > > > > > > > ilp32 and > > > > > > > > > that is bad. > > > > > > > > > > > > > > > > > > 32 bit phys_addr_t on lp64 is irrelevant for actual hardware > > > > > > > > > but this is > > > > > > > > >
Re: [PATCH] sandbox: Correctly define BITS_PER_LONG
On Sat, Oct 22, 2022 at 11:52:29PM +0200, Heinrich Schuchardt wrote: > > > Am 22. Oktober 2022 23:22:01 MESZ schrieb Michal Suchanek : > >SANDBOX_BITS_PER_LONG is the number of bits in long on the sandbox > >platform. > > Please, explain in the commit message what this patch is good for. For setting BITS_PER_LONG correctly. > Aren't further patches needed to make use of it? 'make ue of it' would likely by running 32bit sandbox with 64bit phys_addr_t, and that indeed won't be fixed by this patch alone. Nonetheless, since nobody noticed that this is broken so far I figured I will send the patch anyway. Thanks Michal > Best regards > > Heinrich > > > > >Signed-off-by: Michal Suchanek > >--- > > > > arch/sandbox/include/asm/types.h | 6 +- > > 1 file changed, 1 insertion(+), 5 deletions(-) > > > >diff --git a/arch/sandbox/include/asm/types.h > >b/arch/sandbox/include/asm/types.h > >index c1a5d2af82..5f4b649ee3 100644 > >--- a/arch/sandbox/include/asm/types.h > >+++ b/arch/sandbox/include/asm/types.h > >@@ -18,11 +18,7 @@ typedef unsigned short umode_t; > > /* > > * Number of bits in a C 'long' on this architecture. > > */ > >-#ifdef CONFIG_PHYS_64BIT > >-#define BITS_PER_LONG 64 > >-#else /* CONFIG_PHYS_64BIT */ > >-#define BITS_PER_LONG 32 > >-#endif /* CONFIG_PHYS_64BIT */ > >+#define BITS_PER_LONG CONFIG_SANDBOX_BITS_PER_LONG > > > > #ifdef CONFIG_PHYS_64BIT > > typedef unsigned long long dma_addr_t;
Re: [PATCH] sandbox: Correctly define BITS_PER_LONG
On Sun, Oct 23, 2022 at 09:56:29AM +0200, Heinrich Schuchardt wrote: > On 10/23/22 09:50, Michal Suchánek wrote: > > On Sat, Oct 22, 2022 at 11:52:29PM +0200, Heinrich Schuchardt wrote: > > > > > > > > > Am 22. Oktober 2022 23:22:01 MESZ schrieb Michal Suchanek > > > : > > > > SANDBOX_BITS_PER_LONG is the number of bits in long on the sandbox > > > > platform. > > > > > > Please, explain in the commit message what this patch is good for. > > > > For setting BITS_PER_LONG correctly. > > > > > Aren't further patches needed to make use of it? > > > > 'make ue of it' would likely by running 32bit sandbox with 64bit > > phys_addr_t, and that indeed won't be fixed by this patch alone. > > > > Nonetheless, since nobody noticed that this is broken so far I figured I > > will send the patch anyway. > > > > Thanks > > > > Michal > > > > > Best regards > > > > > > Heinrich > > > > > > > > > > > Signed-off-by: Michal Suchanek > > > > --- > > > > > > > > arch/sandbox/include/asm/types.h | 6 +- > > > > 1 file changed, 1 insertion(+), 5 deletions(-) > > > > > > > > diff --git a/arch/sandbox/include/asm/types.h > > > > b/arch/sandbox/include/asm/types.h > > > > index c1a5d2af82..5f4b649ee3 100644 > > > > --- a/arch/sandbox/include/asm/types.h > > > > +++ b/arch/sandbox/include/asm/types.h > > > > @@ -18,11 +18,7 @@ typedef unsigned short umode_t; > > > > /* > > > > * Number of bits in a C 'long' on this architecture. > > > > */ > > > > -#ifdef CONFIG_PHYS_64BIT > > > > -#define BITS_PER_LONG 64 > CONFIG_PHYS_64BIT defines the length of phys_addr_t. > > BITS_PER_LONG is about the length of long. Sure > > The length of long is defined by the compiler. Sure > phys_addr_t exists for > having a type that is independent of the length of long. sure > > This patch is obviously wrong. That's completely contradictory to what you say above. According to that the patch is obviously right because it changes the definition of BITS_PER_LONG from depending on phys_addr_t to depending on the length of long is defined by the compiler. Thanks Michal > > Best regards > > Heinrich > > > > > -#else /* CONFIG_PHYS_64BIT */ > > > > -#define BITS_PER_LONG 32 > > > > -#endif /* CONFIG_PHYS_64BIT */ > > > > +#define BITS_PER_LONG CONFIG_SANDBOX_BITS_PER_LONG > > > > > > > > #ifdef CONFIG_PHYS_64BIT > > > > typedef unsigned long long dma_addr_t; >
Re: [PATCH v3] console: usb: kbd: Limit poll frequency to improve performance
Hello,
On Wed, Jan 18, 2023 at 05:01:12PM +0100, Filip Žaludek wrote:
>
>
> Hi Michal,
>
> thanks for testing! Do you consider keyboard as working once it is detected
> without
> 'usb_kbd usb_kbd: Timeout poll on interrupt endpoint', or judging from
> subsequent
> typing? Note that issue is reproducible only in about 20% of reboots.
I rely on keyboard input to boot so if it was 20% broken I would notice.
I don't use the rPi all that much so if it was broken only a few
% of the time there is a chance I would miss it.
However, for me not typing on the keyboard during usb detection it is
100% not detected, typing on it during usb detection it is 100%
detected.
The timeout is limitation of the dwc2 controller handling of usb hubs.
There might be a possibility to improve the driver so that it handles
the condition but it might be that the Linux driver relies on a separate
thread handling the controller which is not acceptable for u-boot.
I am not usb expert and definitely not dwc2 expert so I cannot do more
than workaround the current driver limitation.
> For me I can always enter 'U-Boot>' shell, but then keyboard usually does not
> work.
> And yes, resetting the usb controller with pressing a key afterwards will
> finally break the keyboard. ('usb reset' typed from keyboard)
> If you are Prague located I am ready to demonstrate what I am talking about.
>
> Simon's keyboard detection is somewhat interfered by 'SanDisk USB Extreme
> Pro' detection,
> printed complaints but keyboard still works..
> 'usb_kbd usb_kbd: Timeout poll on interrupt endpoint' and 'Failed to get
> keyboard state from device 0c40:8000'
> Btw. why from 0c40:8000 (ELMCU 2.4GHz receiver) when wired keyboard is
> 046d:c31c (Logitech Keyboard K120)?
>
> What is supposed scenario for RPi3/u-boot/grub usb keyboard equipped users
> wanting to boot non-default?
> Enter 'U-Boot>' shell to detect keyboard; type boot; select desired grub
> entry..?
>
> Reverting either from the two makes it non issue for me:
> 'dwc2: use the nonblock argument in submit_int_msg'
> commit 9dcab2c4d2cb50ab1864c818b82a72393c160236
Without this booting from USB is not feasible because reading every
block from the USB drive waits for the keyboard to time out.
> 'console: usb: kbd: Limit poll frequency to improve performance'
> commit 96991e652f541323a03c5b7e075d54a117091618
No idea about this one, for me it doea not give any substantial
difference in behavior.
Thanks
Michal
Re: [PATCH] lmb: Bump CONFIG_LMB_MAX_REGIONS
Hello,
On Wed, Feb 08, 2023 at 01:25:50PM -0500, Tom Rini wrote:
> On Wed, Feb 08, 2023 at 07:24:25PM +0100, Francesco Dolcini wrote:
> > Hello,
> >
> > On Fri, Jan 27, 2023 at 08:54:55AM -0500, Tom Rini wrote:
> > > On Fri, Jan 27, 2023 at 02:00:12PM +0100, Michal Suchanek wrote:
> > > > It is reported that in some configurations it is not possible to boot
> > > > because u-boot runs out of lmbs.
> > > >
> > > > commit 06d514d77c ("lmb: consider EFI memory map") increases lmb usage,
> > > > hence is likely the cause of the lmb overflow.
> > > >
> > > > Fixes: 06d514d77c ("lmb: consider EFI memory map")
> > > > Link: https://bugzilla.opensuse.org/show_bug.cgi?id=1207562
> > > > Signed-off-by: Michal Suchanek
> >
> > Reviewed-by: Francesco Dolcini
> >
> > > I plan to pick up
> > > https://patchwork.ozlabs.org/project/uboot/patch/20230125230823.1567778-1-tr...@konsulko.com/
> > > as the alternative fix for this issue and would suggest that any distro
> > > hitting the problem on v2023.01 apply the above instead of increasing
> > > the limit.
> >
> > Tom, my understanding is that you plan to merge this or an equivalent
> > change, correct? Otherwise I would need to send some more patches to
> > update a few board defconfig that are affected by this specific issue.
>
> Yes, I was hoping to push the equivalent of this patch a few hours ago,
> along with the revert. Then I noticed the test in test/lib/lmb.c doesn't
> scale past 8, and I just now figured out what that should look like
> instead, I believe.
reportedly neither fixes the problem in all cases, and raising
CONFIG_LMB_RESERVED_REGIONS is required.
Looks like the mechanism to add regions above the default number does
not work as intended.
The test is to boot rPi 4 from USB directly with recent firmware.
Thanks
Michal
Re: [PATCH] lmb: Bump CONFIG_LMB_MAX_REGIONS
Hello,
On Sun, Feb 12, 2023 at 06:45:36PM -0500, Tom Rini wrote:
> On Wed, Feb 08, 2023 at 02:50:16PM -0500, Tom Rini wrote:
> > On Wed, Feb 08, 2023 at 08:11:34PM +0100, Michal Suchánek wrote:
> > > Hello,
> > >
> > > On Wed, Feb 08, 2023 at 01:25:50PM -0500, Tom Rini wrote:
> > > > On Wed, Feb 08, 2023 at 07:24:25PM +0100, Francesco Dolcini wrote:
> > > > > Hello,
> > > > >
> > > > > On Fri, Jan 27, 2023 at 08:54:55AM -0500, Tom Rini wrote:
> > > > > > On Fri, Jan 27, 2023 at 02:00:12PM +0100, Michal Suchanek wrote:
> > > > > > > It is reported that in some configurations it is not possible to
> > > > > > > boot
> > > > > > > because u-boot runs out of lmbs.
> > > > > > >
> > > > > > > commit 06d514d77c ("lmb: consider EFI memory map") increases lmb
> > > > > > > usage,
> > > > > > > hence is likely the cause of the lmb overflow.
> > > > > > >
> > > > > > > Fixes: 06d514d77c ("lmb: consider EFI memory map")
> > > > > > > Link: https://bugzilla.opensuse.org/show_bug.cgi?id=1207562
> > > > > > > Signed-off-by: Michal Suchanek
> > > > >
> > > > > Reviewed-by: Francesco Dolcini
> > > > >
> > > > > > I plan to pick up
> > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20230125230823.1567778-1-tr...@konsulko.com/
> > > > > > as the alternative fix for this issue and would suggest that any
> > > > > > distro
> > > > > > hitting the problem on v2023.01 apply the above instead of
> > > > > > increasing
> > > > > > the limit.
> > > > >
> > > > > Tom, my understanding is that you plan to merge this or an equivalent
> > > > > change, correct? Otherwise I would need to send some more patches to
> > > > > update a few board defconfig that are affected by this specific issue.
> > > >
> > > > Yes, I was hoping to push the equivalent of this patch a few hours ago,
> > > > along with the revert. Then I noticed the test in test/lib/lmb.c doesn't
> > > > scale past 8, and I just now figured out what that should look like
> > > > instead, I believe.
> > >
> > > reportedly neither fixes the problem in all cases, and raising
> > > CONFIG_LMB_RESERVED_REGIONS is required.
> > >
> > > Looks like the mechanism to add regions above the default number does
> > > not work as intended.
> > >
> > > The test is to boot rPi 4 from USB directly with recent firmware.
> >
> > Well, given 0089affee275 ("configs: stm32mp15: increase the number of
> > reserved memory region in lmb") I guess this has been run in to before,
> > but not resolved more generically.
>
> I wonder if
> https://patchwork.ozlabs.org/project/uboot/patch/20230212150706.2967007-2-sjo...@collabora.com/
> is what will finish dealing with these issues, even the ones that had
> perhaps shown up before and been addressed in the commit I mentioned
> above?
Looks like this together with raising the maximum number of regions
works, that is v2023.04-rc2 should be fixed.
Thanks
Michal
Re: [PATCH 2/6] clk: Fix error handling in clk_get_rate()
Hello,
On Sun, Feb 19, 2023 at 11:59:35PM -0600, Samuel Holland wrote:
> log_ret() cannot work with unsigned values, and the assignment to 'ret'
> incorrectly truncates the rate from long to int.
>
> Fixes: 5c5992cb90cf ("clk: Add debugging for return values")
> Signed-off-by: Samuel Holland
> ---
>
> drivers/clk/clk-uclass.c | 7 +--
> 1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
> index dc3e9d6a261..78299dbceb2 100644
> --- a/drivers/clk/clk-uclass.c
> +++ b/drivers/clk/clk-uclass.c
> @@ -471,7 +471,6 @@ void clk_free(struct clk *clk)
> ulong clk_get_rate(struct clk *clk)
> {
> const struct clk_ops *ops;
> - int ret;
>
> debug("%s(clk=%p)\n", __func__, clk);
> if (!clk_valid(clk))
> @@ -481,11 +480,7 @@ ulong clk_get_rate(struct clk *clk)
> if (!ops->get_rate)
> return -ENOSYS;
>
> - ret = ops->get_rate(clk);
> - if (ret)
> - return log_ret(ret);
> -
> - return 0;
> + return ops->get_rate(clk);
> }
This is generally poor design of the clock stuff in u-boot.
It returns -ERROR for many error conditions, but also 0 for other error
conditions.
Some error handling checks for 0, some for errval, some casts to int and
checks for <= 0.
I think that using -ERROR for clocks does not make much sense in u-boot.
Even in the kernel the errval checks are pretty much limited to places
where integers are used to store page frame numbers or pointers, that is
errptr stored in an integer. For adresses it is pretty easy to make sure
that the last page is not mapped making the error pointers invalid
(although bugs in that part happened too).
For clocks no such guarantee exists. The only apparently invalid clock
is 0, and the correct fix is to fix up the clock code to return 0 on
error, always. It's a lot of code to fix, though.
If you do not want to fix everything then the correct thing to do is
make ret ulong, and check for errval *and* 0.
There is not much point in returning detailed error codes in u-boot,
anyway. It's not like there is some userspace that could interpret them.
Most errors are logged when they happen if ever, and callers only check
if error happened or not.
Thanks
Michal
Re: [PATCH 3/6] clk: Fix error handling in clk_get_parent()
On Sun, Feb 19, 2023 at 11:59:36PM -0600, Samuel Holland wrote:
> Do not return both NULL and error pointers. The function is only
> documented as returning error pointers.
>
> Fixes: 8a1661f20e6c ("drivers: clk: Handle gracefully NULL pointers")
> Signed-off-by: Samuel Holland
> ---
>
> drivers/clk/clk-uclass.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
> index 78299dbceb2..5bce976b060 100644
> --- a/drivers/clk/clk-uclass.c
> +++ b/drivers/clk/clk-uclass.c
> @@ -490,7 +490,7 @@ struct clk *clk_get_parent(struct clk *clk)
>
> debug("%s(clk=%p)\n", __func__, clk);
> if (!clk_valid(clk))
> - return NULL;
> + return ERR_PTR(-ENODEV);
>
> pdev = dev_get_parent(clk->dev);
> if (!pdev)
Do we really need this?
Who cares about the distinction?
Just returning NULL on any error makes the code so much simpler and
easier to understand.
Thanks
Michal
Re: [PATCH 4/6] clk: Fix rate caching in clk_get_parent_rate()
On Sun, Feb 19, 2023 at 11:59:37PM -0600, Samuel Holland wrote:
> clk_get_rate() can return an error value. Recompute the rate if the
> cached value is an error value.
>
> Fixes: 4aa78300a025 ("dm: clk: Define clk_get_parent_rate() for clk
> operations")
> Signed-off-by: Samuel Holland
> ---
>
> drivers/clk/clk-uclass.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
> index 5bce976b060..9d052e5a814 100644
> --- a/drivers/clk/clk-uclass.c
> +++ b/drivers/clk/clk-uclass.c
> @@ -520,7 +520,8 @@ ulong clk_get_parent_rate(struct clk *clk)
> return -ENOSYS;
>
> /* Read the 'rate' if not already set or if proper flag set*/
> - if (!pclk->rate || pclk->flags & CLK_GET_RATE_NOCACHE)
> + if (!pclk->rate || IS_ERR_VALUE(pclk->rate) ||
> + pclk->flags & CLK_GET_RATE_NOCACHE)
> pclk->rate = clk_get_rate(pclk);
>
> return pclk->rate;
With the current code that randomly returns one or the other this is the
correct thing to do.
Reviewed-by: Michal Suchánek
Thanks
Michal
Re: [PATCH 1/6] clk: Handle error pointers in clk_valid()
On Sun, Feb 19, 2023 at 11:59:34PM -0600, Samuel Holland wrote:
> Some clk uclass functions, such as devm_clk_get() and clk_get_parent(),
> return error pointers. clk_valid() should not consider these pointers
> to be valid.
>
> Fixes: 8a1661f20e6c ("drivers: clk: Handle gracefully NULL pointers")
> Signed-off-by: Samuel Holland
> ---
>
> include/clk.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/clk.h b/include/clk.h
> index d91285235f7..4acb878ec6d 100644
> --- a/include/clk.h
> +++ b/include/clk.h
> @@ -671,7 +671,7 @@ static inline bool clk_dev_binded(struct clk *clk)
> */
> static inline bool clk_valid(struct clk *clk)
> {
> - return clk && !!clk->dev;
> + return clk && !IS_ERR(clk) && !!clk->dev;
> }
>
> int soc_clk_dump(void);
Maybe it would be better to avoid the error pointers instead, there
should not be that many places where they are returned.
Thanks
Michal
Re: [PATCH 5/6] clk: Remove an unneeded check from clk_get_parent_rate()
On Sun, Feb 19, 2023 at 11:59:38PM -0600, Samuel Holland wrote:
> There is no need to check the parent clock's ops. The following call to
> clk_get_rate() does that already.
>
> Signed-off-by: Samuel Holland
> ---
>
> drivers/clk/clk-uclass.c | 5 -
> 1 file changed, 5 deletions(-)
>
> diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
> index 9d052e5a814..53cfd819779 100644
> --- a/drivers/clk/clk-uclass.c
> +++ b/drivers/clk/clk-uclass.c
> @@ -504,7 +504,6 @@ struct clk *clk_get_parent(struct clk *clk)
>
> ulong clk_get_parent_rate(struct clk *clk)
> {
> - const struct clk_ops *ops;
> struct clk *pclk;
>
> debug("%s(clk=%p)\n", __func__, clk);
> @@ -515,10 +514,6 @@ ulong clk_get_parent_rate(struct clk *clk)
> if (IS_ERR(pclk))
> return -ENODEV;
>
> - ops = clk_dev_ops(pclk->dev);
> - if (!ops->get_rate)
> - return -ENOSYS;
> -
> /* Read the 'rate' if not already set or if proper flag set*/
> if (!pclk->rate || IS_ERR_VALUE(pclk->rate) ||
> pclk->flags & CLK_GET_RATE_NOCACHE)
Reviewed-by: Michal Suchánek
Thanks
Michal
Re: [PATCH 2/6] clk: Fix error handling in clk_get_rate()
Hello,
On Mon, Feb 20, 2023 at 11:08:41AM -0500, Sean Anderson wrote:
> On 2/20/23 05:37, Michal Suchánek wrote:
> > Hello,
> >
> > On Sun, Feb 19, 2023 at 11:59:35PM -0600, Samuel Holland wrote:
> > > log_ret() cannot work with unsigned values, and the assignment to 'ret'
> > > incorrectly truncates the rate from long to int.
> > >
> > > Fixes: 5c5992cb90cf ("clk: Add debugging for return values")
> > > Signed-off-by: Samuel Holland
> > > ---
> > >
> > > drivers/clk/clk-uclass.c | 7 +--
> > > 1 file changed, 1 insertion(+), 6 deletions(-)
> > >
> > > diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
> > > index dc3e9d6a261..78299dbceb2 100644
> > > --- a/drivers/clk/clk-uclass.c
> > > +++ b/drivers/clk/clk-uclass.c
> > > @@ -471,7 +471,6 @@ void clk_free(struct clk *clk)
> > > ulong clk_get_rate(struct clk *clk)
> > > {
> > > const struct clk_ops *ops;
> > > - int ret;
> > > debug("%s(clk=%p)\n", __func__, clk);
> > > if (!clk_valid(clk))
> > > @@ -481,11 +480,7 @@ ulong clk_get_rate(struct clk *clk)
> > > if (!ops->get_rate)
> > > return -ENOSYS;
> > > - ret = ops->get_rate(clk);
> > > - if (ret)
> > > - return log_ret(ret);
> > > -
> > > - return 0;
> > > + return ops->get_rate(clk);
> > > }
> >
> > This is generally poor design of the clock stuff in u-boot.
> >
> > It returns -ERROR for many error conditions, but also 0 for other error
> > conditions.
> >
> > Some error handling checks for 0, some for errval, some casts to int and
> > checks for <= 0.
> >
> > I think that using -ERROR for clocks does not make much sense in u-boot.
> >
> > Even in the kernel the errval checks are pretty much limited to places
> > where integers are used to store page frame numbers or pointers, that is
> > errptr stored in an integer. For adresses it is pretty easy to make sure
> > that the last page is not mapped making the error pointers invalid
> > (although bugs in that part happened too).
> >
> > For clocks no such guarantee exists. The only apparently invalid clock
> > is 0, and the correct fix is to fix up the clock code to return 0 on
> > error, always. It's a lot of code to fix, though.
> >
> > If you do not want to fix everything then the correct thing to do is
> > make ret ulong, and check for errval *and* 0.
> >
> > There is not much point in returning detailed error codes in u-boot,
> > anyway. It's not like there is some userspace that could interpret them.
> > Most errors are logged when they happen if ever, and callers only check
> > if error happened or not.
> >
> > Thanks
> >
> > Michal
>
> clk_get_parent is the only place where we return a clock pointer directly.
> Everywhere else, we have an integer return we can use. This function is
> different of course because CCF is broken and assumes there is only one
> canonical struct clk for a logical clock. So it can't initialize a
> caller-passed
> struct clk, but instead has to return the one true struct clk.
>
> I agree with Michal here. The signature should really be
>
> int clk_get_parent(struct clk *child, struct clk *parent)
>
> but for now there is no point confusing the rest of the clock subsystem to
> make
> it work with error pointers.
This is clk_get_rate. It returns a clock rate. A clock rate of 2.5GHz is
not out of question, and cannot be expressed with a signed integer.
Hence clock rate should not be treated as signed, and -ERROR should not
be returned as clock rate.
Thanks
Michal
Re: [PATCH 1/6] clk: Handle error pointers in clk_valid()
On Mon, Feb 20, 2023 at 10:57:17AM -0500, Sean Anderson wrote:
>
> On 2/20/23 05:46, Michal Suchánek wrote:
> > On Sun, Feb 19, 2023 at 11:59:34PM -0600, Samuel Holland wrote:
> > > Some clk uclass functions, such as devm_clk_get() and clk_get_parent(),
> > > return error pointers. clk_valid() should not consider these pointers
> > > to be valid.
> > >
> > > Fixes: 8a1661f20e6c ("drivers: clk: Handle gracefully NULL pointers")
> > > Signed-off-by: Samuel Holland
> > > ---
> > >
> > > include/clk.h | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/include/clk.h b/include/clk.h
> > > index d91285235f7..4acb878ec6d 100644
> > > --- a/include/clk.h
> > > +++ b/include/clk.h
> > > @@ -671,7 +671,7 @@ static inline bool clk_dev_binded(struct clk *clk)
> > >*/
> > > static inline bool clk_valid(struct clk *clk)
> > > {
> > > - return clk && !!clk->dev;
> > > + return clk && !IS_ERR(clk) && !!clk->dev;
> > > }
> > > int soc_clk_dump(void);
> >
> > Maybe it would be better to avoid the error pointers instead, there
> > should not be that many places where they are returned.
>
> This not quite the right way to phrase this. Instead, I would ask: where
> are places where the return value is not checked correctly? It's perfectly
Pretty much everywhere where clk_get_parent is used outside of core code
absolutely no error checking is done.
> fine to pass NULL or uninitialized clocks to other clock functions, but it's
> not OK to ignore errors.
Is there some documentation on what is the distinction, specifically?
If there isn't it's meaningless and NULL can be returned on error
simplifying the code, thinking about the code, debugging, pretty much
everything.
Thanks
Michal
Re: [PATCH v2 1/2] power: pmic: rk8xx: Support sysreset shutdown method
On Fri, Jul 15, 2022 at 12:10:47PM -0500, Chris Morgan wrote:
> On Thu, Jul 07, 2022 at 10:41:34AM +0200, Michal Suchánek wrote:
> > Hello,
> >
> > this causes regression on pinebook pro:
> >
> > resetting ...
> > System reset not supported on this platform
> > ### ERROR ### Please RESET the board ###
> >
> > Is there something missing in the DT for this board?
> >
> > Or perhaps a fallback should be provided in absence of the PMIC?
> >
> > Thanks
> >
> > Michal
>
> Sorry Michal, I was busy traveling and then came down with a pretty bad
> cold, so I've been a bit away from things. Are you getting this error
> when you attempt to reset or to poweroff the Pinebook Pro from U-Boot?
>
> I tested the code on my RK817, but a cursory reading of the datasheet
> suggests every rk8xx known so far should be able to shutdown using the
> two methods added here. I'm wondering if there is perhaps a configuration
> issue we need to account for, as this routine is only shutting down the
> PMIC and not restarting it.
This is trying to restart the system from u-boot.
The walk function *seems* to try all methods of all reset providers but
maybe there is some catch there.
Thanks
Michal
>
> Thank you.
>
> >
> > On Fri, May 27, 2022 at 01:18:19PM -0500, Chris Morgan wrote:
> > > From: Chris Morgan
> > >
> > > Add support for sysreset shutdown for this PMIC. The values were pulled
> > > from the various datasheets, but for now it has only been tested on
> > > the rk817 (for an Odroid Go Advance).
> > >
> > > Signed-off-by: Chris Morgan
> > > Reviewed-by: Jaehoon Chung
> > > Reviewed-by: Kever Yang
> > > ---
> > > drivers/power/pmic/rk8xx.c | 50 +-
> > > 1 file changed, 49 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/power/pmic/rk8xx.c b/drivers/power/pmic/rk8xx.c
> > > index 5f442fea68..1ffbecc02a 100644
> > > --- a/drivers/power/pmic/rk8xx.c
> > > +++ b/drivers/power/pmic/rk8xx.c
> > > @@ -6,10 +6,50 @@
> > >
> > > #include
> > > #include
> > > +#include
> > > #include
> > > #include
> > > #include
> > > #include
> > > +#include
> > > +
> > > +static int rk8xx_sysreset_request(struct udevice *dev, enum sysreset_t
> > > type)
> > > +{
> > > + struct rk8xx_priv *priv = dev_get_priv(dev->parent);
> > > +
> > > + if (type != SYSRESET_POWER_OFF)
> > > + return -EPROTONOSUPPORT;
> > > +
> > > + switch (priv->variant) {
> > > + case RK805_ID:
> > > + case RK808_ID:
> > > + case RK816_ID:
> > > + case RK818_ID:
> > > + pmic_clrsetbits(dev->parent, REG_DEVCTRL, 0, BIT(0));
> > > + break;
> > > + case RK809_ID:
> > > + case RK817_ID:
> > > + pmic_clrsetbits(dev->parent, RK817_REG_SYS_CFG3, 0,
> > > + BIT(0));
> > > + break;
> > > + default:
> > > + printf("Unknown PMIC RK%x: Cannot shutdown\n",
> > > +priv->variant);
> > > + return -EPROTONOSUPPORT;
> > > + };
> > > +
> > > + return -EINPROGRESS;
> > > +}
> > > +
> > > +static struct sysreset_ops rk8xx_sysreset_ops = {
> > > + .request= rk8xx_sysreset_request,
> > > +};
> > > +
> > > +U_BOOT_DRIVER(rk8xx_sysreset) = {
> > > + .name = "rk8xx_sysreset",
> > > + .id = UCLASS_SYSRESET,
> > > + .ops= &rk8xx_sysreset_ops,
> > > +};
> > >
> > > static struct reg_data rk817_init_reg[] = {
> > > /* enable the under-voltage protection,
> > > @@ -61,7 +101,7 @@ static int rk8xx_read(struct udevice *dev, uint reg,
> > > uint8_t *buff, int len)
> > > static int rk8xx_bind(struct udevice *dev)
> > > {
> > > ofnode regulators_node;
> > > - int children;
> > > + int children, ret;
> > >
> > > regulators_node = dev_read_subnode(dev, "regulators");
> > > if (!ofnode_valid(regulators_node)) {
> > > @@ -72,6 +112,14 @@ static int rk8xx_bind(struct udevice *dev)
> > >
> > > debug("%s: '%s' - found regulators subnode\n", __func__, dev->name);
> > >
> > > + if (CONFIG_IS_ENABLED(SYSRESET)) {
> > > + ret = device_bind_driver_to_node(dev, "rk8xx_sysreset",
> > > + "rk8xx_sysreset",
> > > + dev_ofnode(dev), NULL);
> > > + if (ret)
> > > + return ret;
> > > + }
> > > +
> > > children = pmic_bind_children(dev, regulators_node, pmic_children_info);
> > > if (!children)
> > > debug("%s: %s - no child found\n", __func__, dev->name);
> > > --
> > > 2.25.1
> > >
Re: [PATCH v2 1/2] power: pmic: rk8xx: Support sysreset shutdown method
On Fri, Jul 15, 2022 at 07:18:07PM +0200, Michal Suchánek wrote:
> On Fri, Jul 15, 2022 at 12:10:47PM -0500, Chris Morgan wrote:
> > On Thu, Jul 07, 2022 at 10:41:34AM +0200, Michal Suchánek wrote:
> > > Hello,
> > >
> > > this causes regression on pinebook pro:
> > >
> > > resetting ...
> > > System reset not supported on this platform
> > > ### ERROR ### Please RESET the board ###
> > >
> > > Is there something missing in the DT for this board?
> > >
> > > Or perhaps a fallback should be provided in absence of the PMIC?
> > >
> > > Thanks
> > >
> > > Michal
> >
> > Sorry Michal, I was busy traveling and then came down with a pretty bad
> > cold, so I've been a bit away from things. Are you getting this error
> > when you attempt to reset or to poweroff the Pinebook Pro from U-Boot?
> >
> > I tested the code on my RK817, but a cursory reading of the datasheet
> > suggests every rk8xx known so far should be able to shutdown using the
> > two methods added here. I'm wondering if there is perhaps a configuration
> > issue we need to account for, as this routine is only shutting down the
> > PMIC and not restarting it.
>
> This is trying to restart the system from u-boot.
>
> The walk function *seems* to try all methods of all reset providers but
> maybe there is some catch there.
After adding debug prints it looks like no sysreset uclass is found
anymore after the patch:
diff --git a/drivers/sysreset/sysreset-uclass.c
b/drivers/sysreset/sysreset-uclass.c
index 279b087d16..4a144e517f 100644
--- a/drivers/sysreset/sysreset-uclass.c
+++ b/drivers/sysreset/sysreset-uclass.c
@@ -5,6 +5,7 @@
*/
#define LOG_CATEGORY UCLASS_SYSRESET
+#define DEBUG
#include
#include
@@ -53,6 +54,18 @@ int sysreset_get_last(struct udevice *dev)
return ops->get_last(dev);
}
+static inline const char * sysreset_to_str(enum sysreset_t reset)
+{
+ switch (reset) {
+ case SYSRESET_WARM: return "warm restart";
+ case SYSRESET_COLD: return "cold restart";
+ case SYSRESET_POWER: return "power cycle";
+ case SYSRESET_POWER_OFF: return "power off";
+ case SYSRESET_COUNT: break;
+ }
+ return "unknown";
+}
+
int sysreset_walk(enum sysreset_t type)
{
struct udevice *dev;
@@ -62,9 +75,14 @@ int sysreset_walk(enum sysreset_t type)
for (uclass_first_device(UCLASS_SYSRESET, &dev);
dev;
uclass_next_device(&dev)) {
+ debug("trying reset %s on %s...", dev->name,
+ sysreset_to_str(type));
ret = sysreset_request(dev, type);
- if (ret == -EINPROGRESS)
+ if (ret == -EINPROGRESS) {
+ debug("done\n");
break;
+ }
+ debug("\n");
}
type++;
}
--
2.36.1
With sysreset patch reverted
Hit any key to stop autoboot: 0
=> reset
resetting ...
trying reset sysreset on cold restart...
U-Boot TPL 2022.07-00027-gd9cc607b5e-dirty (Jul 16 2022 - 16:15:27)
With sysreset support included
Hit any key to stop autoboot: 0
=> reset
resetting ...
System reset not supported on this platform
### ERROR ### Please RESET the board ###
The error is printed here:
void sysreset_walk_halt(enum sysreset_t type)
{
int ret;
ret = sysreset_walk(type);
/* Wait for the reset to take effect */
if (ret == -EINPROGRESS)
mdelay(100);
/* Still no reset? Give up */
if (spl_phase() <= PHASE_SPL)
log_err("no sysreset\n");
else
log_err("System reset not supported on this platform\n");
hang();
}
Re: [PATCH v2 5/5] rockchip: rock-pi-4: dts: spi: Make the index of the spi flash the same in SPL and U-Boot proper
On Mon, Jul 18, 2022 at 10:33:18AM +0200, Quentin Schulz wrote: > Hi Xavier, > > On 7/15/22 18:30, Xavier Drudis Ferran wrote: > > Spi0 is not needed in SPL and SPL could be a little smaller without it, > > but then the SF_DEFAULT_BOOT would have to be 0 to refer to spi1, and > > that's confusing, because once U-Boot proper runs, it numbers the bus 1. > > > > Add spi0 to the pre-reloc and spl trees so that the flash is always > > connected to bus 1. > > > > Mmmm... Could we instead make U-Boot use the bus number from the alias in > the aliases DT node? I think the mmc subsystem does this already and it > would mean we don't need to enable unnecessary devices. Also, relying on It does not seem to work for mmc, though. I have mmc2 and mmc1 in SPL, and mmc1 and mmc0 in u-boot. There are actually 3 mmc interfaces using 2 drivers so the situations is .. complex. Thanks Michal
Re: [PATCH v2 5/5] rockchip: rock-pi-4: dts: spi: Make the index of the spi flash the same in SPL and U-Boot proper
On Mon, Jul 18, 2022 at 11:09:56AM +0200, Xavier Drudis Ferran wrote:
> El Mon, Jul 18, 2022 at 10:33:18AM +0200, Quentin Schulz deia:
> > Hi Xavier,
> >
> > On 7/15/22 18:30, Xavier Drudis Ferran wrote:
> > > Spi0 is not needed in SPL and SPL could be a little smaller without it,
> > > but then the SF_DEFAULT_BOOT would have to be 0 to refer to spi1, and
> > > that's confusing, because once U-Boot proper runs, it numbers the bus 1.
> > >
> > > Add spi0 to the pre-reloc and spl trees so that the flash is always
> > > connected to bus 1.
> > >
> >
> > Mmmm... Could we instead make U-Boot use the bus number from the alias in
> > the aliases DT node? I think the mmc subsystem does this already and it
> > would mean we don't need to enable unnecessary devices. Also, relying on
> > boot order for the bus number is brittle in Linux, I don't know about
> > U-Boot, but if we can avoid this assumption, it'd be great :)
> >
> > See:
> > https://source.denx.de/u-boot/u-boot/-/commit/2243d19e5618122d9d7aba23eb51f63f2719dba5
> > for how to do it today?
> >
>
> Maybe I should just drop this patch and try to define
> CONFIG_SPL_DM_SEQ_ALIAS in configs/rock-pi-4-rk3399 instead ?
> Let me test this a little...
>
> I have CONFIG_DM_SEQ_ALIAS=y but CONFIG_SPL_DM_SEQ_ALIAS unset.
>
> >
> > Your patch series got sent with each commit in their individual thread
>
> I know. Sorry for the lapsus. I did it right in v1, wrong in v2, and will do
> right in v3.
What is actually the correct naming here?
We have in arch/arm/mach-rockchip/rk3399/rk3399.c
const char * const boot_devices[BROM_LAST_BOOTSOURCE + 1] = {
[BROM_BOOTSOURCE_EMMC] = "/sdhci@fe33",
[BROM_BOOTSOURCE_SPINOR] = "/spi@ff1d/flash@0",
[BROM_BOOTSOURCE_SD] = "/mmc@fe32",
};
} spl_boot_devices_tbl[] = {
{ BOOT_DEVICE_MMC1, "/mmc@fe32" },
{ BOOT_DEVICE_MMC2, "/sdhci@fe33" },
{ BOOT_DEVICE_SPI, "/spi@ff1d" },
};
which then presumably gets converted in common/spl/spl_mmc.c
SPL_LOAD_IMAGE_METHOD("MMC1", 0, BOOT_DEVICE_MMC1, spl_mmc_load_image);
SPL_LOAD_IMAGE_METHOD("MMC2", 0, BOOT_DEVICE_MMC2, spl_mmc_load_image);
SPL_LOAD_IMAGE_METHOD("MMC2_2", 0, BOOT_DEVICE_MMC2_2, spl_mmc_load_image);
We then have this in rk3399.dtsi:
sdio0: mmc@fe31 {
compatible = "rockchip,rk3399-dw-mshc",
sdmmc: mmc@fe32 {
compatible = "rockchip,rk3399-dw-mshc",
sdhci: mmc@fe33 {
compatible = "rockchip,rk3399-sdhci-5.1", "arasan,sdhci-5.1";
and this in rk3399-u-boot.dtsi
mmc0 = &sdhci;
mmc1 = &sdmmc;
and this in arch/arm/dts/rk3399-pinebook-pro.dts
aliases {
mmc0 = &sdio0;
mmc1 = &sdmmc;
mmc2 = &sdhci;
};
mmc@fe31: 3
mmc@fe32: 1 (SD)
mmc@fe33: 0 (eMMC)
This is not consistent with any of the above.
Also on upstream kernel eMMC is mmc0 and SD mmc1 (somewhat consistently
with the above), while on downstream kernel it seems these are mmc1 and
mmc2, respectively.
Thanks
Michal
Re: [PATCH v2 5/5] rockchip: rock-pi-4: dts: spi: Make the index of the spi flash the same in SPL and U-Boot proper
On Mon, Jul 18, 2022 at 03:01:25PM +0200, Quentin Schulz wrote:
> Hi Michal,
>
> On 7/18/22 13:00, Michal Suchánek wrote:
> > On Mon, Jul 18, 2022 at 11:09:56AM +0200, Xavier Drudis Ferran wrote:
> > > El Mon, Jul 18, 2022 at 10:33:18AM +0200, Quentin Schulz deia:
> > > > Hi Xavier,
> > > >
> > > > On 7/15/22 18:30, Xavier Drudis Ferran wrote:
> > > > > Spi0 is not needed in SPL and SPL could be a little smaller without
> > > > > it,
> > > > > but then the SF_DEFAULT_BOOT would have to be 0 to refer to spi1, and
> > > > > that's confusing, because once U-Boot proper runs, it numbers the bus
> > > > > 1.
> > > > >
> > > > > Add spi0 to the pre-reloc and spl trees so that the flash is always
> > > > > connected to bus 1.
> > > > >
> > > >
> > > > Mmmm... Could we instead make U-Boot use the bus number from the alias
> > > > in
> > > > the aliases DT node? I think the mmc subsystem does this already and it
> > > > would mean we don't need to enable unnecessary devices. Also, relying on
> > > > boot order for the bus number is brittle in Linux, I don't know about
> > > > U-Boot, but if we can avoid this assumption, it'd be great :)
> > > >
> > > > See:
> > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__source.denx.de_u-2Dboot_u-2Dboot_-2D_commit_2243d19e5618122d9d7aba23eb51f63f2719dba5&d=DwIBAg&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=G-LrZmlVXqwFFza02frCo5F8vUCol4vDYe6RpSOpezwdgWuNQZyIB2hF_SNO4Gz3&s=O9wEK10SUOQNv_9zcY0K2oSdD_soaQtgjga-pw9nAgY&e=
> > > > for how to do it today?
> > > >
> > >
> > > Maybe I should just drop this patch and try to define
> > > CONFIG_SPL_DM_SEQ_ALIAS in configs/rock-pi-4-rk3399 instead ?
> > > Let me test this a little...
> > >
> > > I have CONFIG_DM_SEQ_ALIAS=y but CONFIG_SPL_DM_SEQ_ALIAS unset.
> > >
> > > >
> > > > Your patch series got sent with each commit in their individual thread
> > >
> > > I know. Sorry for the lapsus. I did it right in v1, wrong in v2, and will
> > > do right in v3.
> >
> > What is actually the correct naming here?
> >
> > We have in arch/arm/mach-rockchip/rk3399/rk3399.c
> >
> > const char * const boot_devices[BROM_LAST_BOOTSOURCE + 1] = {
> > [BROM_BOOTSOURCE_EMMC] = "/sdhci@fe33",
> > [BROM_BOOTSOURCE_SPINOR] = "/spi@ff1d/flash@0",
> > [BROM_BOOTSOURCE_SD] = "/mmc@fe32",
> > };
> >
> > } spl_boot_devices_tbl[] = {
> > { BOOT_DEVICE_MMC1, "/mmc@fe32" },
> > { BOOT_DEVICE_MMC2, "/sdhci@fe33" },
> > { BOOT_DEVICE_SPI, "/spi@ff1d" },
> > };
> >
>
> This one was incorrect for boards not redefining the aliases nodes for mmc
> devices from rk3399-u-boot.dtsi and I've sent a patch for it:
> https://lore.kernel.org/u-boot/20220715151552.953654-1-foss+ub...@0leil.net/
Which actually sounds reasonable.
>
> > which then presumably gets converted in common/spl/spl_mmc.c
> >
> > SPL_LOAD_IMAGE_METHOD("MMC1", 0, BOOT_DEVICE_MMC1, spl_mmc_load_image);
> > SPL_LOAD_IMAGE_METHOD("MMC2", 0, BOOT_DEVICE_MMC2, spl_mmc_load_image);
> > SPL_LOAD_IMAGE_METHOD("MMC2_2", 0, BOOT_DEVICE_MMC2_2, spl_mmc_load_image);
> >
>
> I actually think from spl_mmc_get_device_index()?
The above gives the user-visible string.
spl_mmc_get_device_index establishes the off-by-one between boot devices
and indexes:
static int spl_mmc_get_device_index(u32 boot_device)
{
switch (boot_device) {
case BOOT_DEVICE_MMC1:
return 0;
case BOOT_DEVICE_MMC2:
case BOOT_DEVICE_MMC2_2:
return 1;
}
>
> > We then have this in rk3399.dtsi:
> >
> > sdio0: mmc@fe31 {
> > compatible = "rockchip,rk3399-dw-mshc",
> >
> > sdmmc: mmc@fe32 {
> > compatible = "rockchip,rk3399-dw-mshc",
> >
> > sdhci: mmc@fe33 {
> > compatible = "rockchip,rk3399-sdhci-5.1",
> > "arasan,sdhci-5.1";
> >
> > and this in rk3399-u-boot.dtsi
> >
> > mmc0 = &sdhci;
> >
Re: [PATCH v2 5/5] rockchip: rock-pi-4: dts: spi: Make the index of the spi flash the same in SPL and U-Boot proper
On Mon, Jul 18, 2022 at 03:14:33PM +0200, Xavier Drudis Ferran wrote: > El Mon, Jul 18, 2022 at 01:00:03PM +0200, Michal Suchánek deia: > > > mmc@fe31: 3 > > mmc@fe32: 1 (SD) > > mmc@fe33: 0 (eMMC) > > > > This is not consistent with any of the above. > > > > I agree, but this is mmc, and this thread was about spi. Sorry for hijacking your thread then. I was probably looking for the other patch that adjusts the mmc indexes. Thanks Michal
Re: [bug] boot failure on pinebook pro due to rk8xx changes in 2022.07
Hello, On Mon, Jul 18, 2022 at 05:37:18PM -0500, Chris Morgan wrote: > On Mon, Jul 18, 2022 at 03:39:43PM +0200, Jan Palus wrote: > > u-boot 2022.07 successfully finds and loads kernel (5.18.3) on my > > Pinebook Pro however boot process fails when loading rk808 module: > > > > rk3x-i2c ff3c.i2c: timeout, ipd: 0x00, state: 1 > > rk808 0-001b: failed to read the chip id at 0x17 > > rk808: probe of 0-001b failed with error -110 > > > > git bisect indicates first commit to cause regression: > > > > commit ad607512f5757f4485968efd5bcf2c0245a8a235 (refs/bisect/bad) > > Author: Chris Morgan > > Date: Fri May 27 20:18:19 2022 > > > > power: pmic: rk8xx: Support sysreset shutdown method > > > > Add support for sysreset shutdown for this PMIC. The values were > > pulled > > from the various datasheets, but for now it has only been tested on > > the rk817 (for an Odroid Go Advance). > > > > Signed-off-by: Chris Morgan > > Reviewed-by: Jaehoon Chung > > Reviewed-by: Kever Yang > > > > Reverting this commit fixes the issue and upon rk808 module load > > following is logged: > > > > rk808 0-001b: chip id: 0x0 > > This is strange, as I've not encountered this bug. However, as this is > the second report of a problem with the Pinebook Pro and this patch I > wonder if it's prudent to roll this back (until such time that the > functionality can be made board specific rather than generic to the > PMIC). Observed problems after the patch: - cannot reset board from u-boot - the sysreset walk function does not find any sysreset uclass device and halts - the pmic is no longer probed - the PMIC: RK808 message (with a trailing space) is no longer printed during u-boot startup - linux locks up during boot - there is some complaint about fan53555 regulators which is no longer printed during boot I tried to not error out when the sysreset bind fails, and not bind it to DT node (device_bind_driver_to_node -> device_bind_driver) but it does not make any difference. I do not use the later part with staying off after plug-in which is not needed on this board so I don't really understand what's the difference. Thanks Michal
Re: [PATCH] Revert "power: pmic: rk8xx: Support sysreset shutdown method"
Hello,
On Sat, Jul 23, 2022 at 10:42:36AM -0600, Simon Glass wrote:
> Hi Chris,
>
> On Fri, 22 Jul 2022 at 11:32, Chris Morgan wrote:
> >
> > From: Chris Morgan
> >
> > This reverts commit ad607512f5757f4485968efd5bcf2c0245a8a235.
> >
> > It was found during extensive testing that this causes problems
> > on certain boards. I was able to test this patch on a second
>
> Please can you describe the problem in the commit message?
>
> > device (an Anbernic RG353) and it resulted in similar failures.
> >
> > Signed-off-by: Chris Morgan
> > ---
> > drivers/power/pmic/rk8xx.c | 50 +-
> > 1 file changed, 1 insertion(+), 49 deletions(-)
> >
I would like to know what's wrrong with the code, actually.
I replaced the registration with this code:
debug("%s: '%s' - found regulators subnode\n", __func__, dev->name);
if (CONFIG_IS_ENABLED(SYSRESET)) {
struct udevice *udev = NULL;
printf("sysresets:");
for (uclass_first_device(UCLASS_SYSRESET, &udev);
udev;
uclass_next_device(&udev)) {
printf(" %s", udev->name);
}
printf("\n");
device_bind_driver(dev, "rk8xx_sysreset", "rk8xx_sysreset",
NULL);
printf("sysresets:");
for (uclass_first_device(UCLASS_SYSRESET, &udev);
udev;
uclass_next_device(&udev)) {
printf(" %s", udev->name);
}
printf("\n");
}
children = pmic_bind_children(dev, regulators_node, pmic_children_info);
And added soem debug code to uclass:
int uclass_bind_device(struct udevice *dev)
{
struct uclass *uc;
+ struct udevice *ud;
int ret;
uc = dev->uclass;
+ debug("Binding %s to %s", dev->name, uc->uc_drv->name);
+ list_for_each_entry(ud, &uc->dev_head, uclass_node)
+ debug(" %s", ud->name);
+ debug("\n");
list_add_tail(&dev->uclass_node, &uc->dev_head);
+ debug("Bound %s to %s", dev->name, uc->uc_drv->name);
+ list_for_each_entry(ud, &uc->dev_head, uclass_node)
+ debug(" %s", ud->name);
+ debug("\n");
With this I get this output:
Binding pmic@1b to pmic
Bound pmic@1b to pmic pmic@1b
sysresets:
Binding rk8xx_sysreset to sysreset
Bound rk8xx_sysreset to sysreset rk8xx_sysreset
sysresets:Looking for pmu-clock-controller@ff75
Looking for pmu-clock-controller@ff75
- result for pmu-clock-controller@ff75: (none) (ret=-19)
- result for pmu-clock-controller@ff75: (none) (ret=-19)
Binding DCDC_REG1 to regulator
So the sysreset is actually bound to the class, and then unbound again.
When does this happen?
Can also other devices get removed from their class and then failing to
get located by code that walks class lists?
Also how does the "Looking for pmu-clock-controller@ff75" get
printed in the middle of the debug print?
Note that the debug print is sysresets:, then emty list of sysresets,
and then newline which is printed after the messages about pmu-clock.
Thanks
Michal
Re: [PATCH] dm: core: Do not stop uclass iteration on error.
Hello,
On Thu, Aug 04, 2022 at 01:22:57PM -0600, Simon Glass wrote:
> Hi Michal,
>
> On Thu, 4 Aug 2022 at 11:59, Michal Suchanek wrote:
> >
> > When probing a device fails NULL pointer is returned, and other devices
> > cannot be iterated. Skip to next device on error instead.
> >
> > Fixes: 6494d708bf ("dm: Add base driver model support")
> > Signed-off-by: Michal Suchanek
> > ---
> > drivers/core/uclass.c | 30 +-
> > 1 file changed, 21 insertions(+), 9 deletions(-)
>
> Are you able to create a test for this, e.g. in test/dm/core.c or test-fdt.c ?
>
> Some sandbox devices can be made to give an error, so the test can
> check the logic.
>
> Strangely enough, this is actually a very big change, so we need to be
> careful.
Right, I can have a look at doing some tests.
Knowing what the problem is designig a test should not be too difficult.
It does not make the change any smaller but it can at least prevent
regressions.
Not sure when I get to it, though.
Thanks
Michal
>
> >
> > diff --git a/drivers/core/uclass.c b/drivers/core/uclass.c
> > index 08d9ed82de..ccf7d59141 100644
> > --- a/drivers/core/uclass.c
> > +++ b/drivers/core/uclass.c
> > @@ -574,16 +574,31 @@ int uclass_get_device_by_phandle(enum uclass_id id,
> > struct udevice *parent,
> > }
> > #endif
> >
> > +/* Starting from the given device return first device in the uclass that
> > probes successfully */
> > +static int __uclass_next_device(struct udevice *dev, int ret, struct
> > udevice **devp)
> > +{
> > + if (!dev) {
> > + *devp = dev;
> > + return 0;
> > + }
> > + while ((ret = uclass_get_device_tail(dev, ret, devp))) {
> > + ret = uclass_find_next_device(&dev);
> > + if (!dev) {
> > + *devp = dev;
> > + return 0;
> > + }
> > + }
> > +
> > + return ret;
> > +}
> > +
> > int uclass_first_device(enum uclass_id id, struct udevice **devp)
> > {
> > - struct udevice *dev;
> > + struct udevice *dev = NULL;
> > int ret;
> >
> > - *devp = NULL;
> > ret = uclass_find_first_device(id, &dev);
> > - if (!dev)
> > - return 0;
> > - return uclass_get_device_tail(dev, ret, devp);
> > + return __uclass_next_device(dev, ret, devp);
> > }
> >
> > int uclass_first_device_err(enum uclass_id id, struct udevice **devp)
> > @@ -604,11 +619,8 @@ int uclass_next_device(struct udevice **devp)
> > struct udevice *dev = *devp;
> > int ret;
> >
> > - *devp = NULL;
> > ret = uclass_find_next_device(&dev);
> > - if (!dev)
> > - return 0;
> > - return uclass_get_device_tail(dev, ret, devp);
> > + return __uclass_next_device(dev, ret, devp);
> > }
> >
> > int uclass_next_device_err(struct udevice **devp)
> > --
> > 2.37.1
> >
>
> Regards,
> Simon
Re: [PATCH] doc: dm: clarify activation.
On Thu, Aug 04, 2022 at 01:22:53PM -0600, Simon Glass wrote: > Hi Michal, > > On Thu, 4 Aug 2022 at 11:58, Michal Suchanek wrote: > > > > Explain when devices should get activated. > > > > Signed-off-by: Michal Suchanek > > --- > > doc/develop/driver-model/design.rst | 22 -- > > 1 file changed, 20 insertions(+), 2 deletions(-) > > Reviewed-by: Simon Glass > > Much appreciated! > > one note below > > > > > diff --git a/doc/develop/driver-model/design.rst > > b/doc/develop/driver-model/design.rst > > index 5f33f9fbb3..c925d21b24 100644 > > --- a/doc/develop/driver-model/design.rst > > +++ b/doc/develop/driver-model/design.rst > > @@ -794,8 +794,26 @@ fall afoul of this rule. > > Activation/probe > > > > > > -When a device needs to be used, U-Boot activates it, by first reading > > ofdata > > -as above and then following these steps (see device_probe()): > > +To save resources devices in U-Boot are probed lazily. U-Boot is a > > bootloader, > > +not an operating system. Many devices are never used during an U-Boot run, > > and > > +probing them takes time, requires memory, may add delays to the main loop, > > etc. > > + > > +The device should be probed by the uclass code. Different uclasses are > > or the device code (e.g. device_get_child()) Can you elaborate a bit more, please? This change is the reasult of some previous discussion about the device activation with Marek. The device activation is really difficult to understand for people who did not participate in designing the DM, and is probably quite specific to U-Boot. > > BTW probing a child probes all its parents automatically (that is said > elsewhere I think). Yes, right below this part. Thanks Michal > > > +different but two common use cases can be seen: > > + > > + 1. The uclass is asked to look up a specific device, such as SPI bus 0, > > + first chip select - in this case the returned device should be > > + activated. > > + > > + 2. The uclass is asked to perform a specific function on any device that > > + supports it, eg. reset the board using any sysreset that can be found - > > + for this case the core uclass code provides iterators that activate > > + each device before returning it, and the uclass typically implements a > > + walk function that iterates over all devices of the uclass and tries > > + to perform the requested function on each in turn until succesful. > > + > > +To activate a device U-Boot first reads ofdata as above and then follows > > these > > +steps (see device_probe()): > > > > 1. All parent devices are probed. It is not possible to activate a > > device > > unless its predecessors (all the way up to the root device) are > > activated. > > -- > > 2.37.1 > > > > Regards, > Simon
Re: [PATCH] power: pmic: rk8xx: Workaround pmic failure when probed before relocation
On Fri, Aug 05, 2022 at 10:48:26AM -0600, Simon Glass wrote:
> Hi Michal,
>
> On Fri, 5 Aug 2022 at 05:32, Michal Suchanek wrote:
> >
> > When the sysreset is added as child of the pmic the pmic is probed
> > before relocation. That probe fails, and subsequent attempts to probe
> > after reloaction fail as well.
> >
> > As a workaround do not bind the sysreset before relocation.
> >
> > Signed-off-by: Michal Suchanek
> > ---
> > drivers/power/pmic/rk8xx.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/power/pmic/rk8xx.c b/drivers/power/pmic/rk8xx.c
> > index a239a18674..d12263c4f2 100644
> > --- a/drivers/power/pmic/rk8xx.c
> > +++ b/drivers/power/pmic/rk8xx.c
> > @@ -131,7 +131,7 @@ static int rk8xx_read(struct udevice *dev, uint reg,
> > uint8_t *buff, int len)
> >
> > static int rk8xx_bind(struct udevice *dev)
> > {
> > - if (CONFIG_IS_ENABLED(SYSRESET)) {
> > + if (CONFIG_IS_ENABLED(SYSRESET) && (gd->flags & GD_FLG_RELOC)) {
> > device_bind_driver(dev, "rk8xx_sysreset",
> >"rk8xx_sysreset", NULL);
> > }
> > --
> > 2.37.1
> >
>
> I think it is OK to avoid starting a device before relocation, or make
> that device do something different. I really don't like the binding
> being optional though...we have the 'u-boot,dm-pre-reloc' for that.
So perhaps the flag should be dropped from rk8xx then.
>
> But missing from your commit message is exactly what fails?
The pmic is an i2c device, all i2c tranferss fail if initialized
pre-relocation. I supect it's the i2c bus that fails if initialized
before reloc - the regulatorss that share the i2c bus also report i2c
transfer failure.
Thanks
Michal
Re: [PATCH] power: pmic: rk8xx: Workaround pmic failure when probed before relocation
On Sat, Aug 06, 2022 at 12:21:29PM -0600, Simon Glass wrote:
> Hi Michal,
>
> On Fri, 5 Aug 2022 at 14:07, Michal Suchánek wrote:
> >
> > On Fri, Aug 05, 2022 at 10:48:26AM -0600, Simon Glass wrote:
> > > Hi Michal,
> > >
> > > On Fri, 5 Aug 2022 at 05:32, Michal Suchanek wrote:
> > > >
> > > > When the sysreset is added as child of the pmic the pmic is probed
> > > > before relocation. That probe fails, and subsequent attempts to probe
> > > > after reloaction fail as well.
> > > >
> > > > As a workaround do not bind the sysreset before relocation.
> > > >
> > > > Signed-off-by: Michal Suchanek
> > > > ---
> > > > drivers/power/pmic/rk8xx.c | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/power/pmic/rk8xx.c b/drivers/power/pmic/rk8xx.c
> > > > index a239a18674..d12263c4f2 100644
> > > > --- a/drivers/power/pmic/rk8xx.c
> > > > +++ b/drivers/power/pmic/rk8xx.c
> > > > @@ -131,7 +131,7 @@ static int rk8xx_read(struct udevice *dev, uint
> > > > reg, uint8_t *buff, int len)
> > > >
> > > > static int rk8xx_bind(struct udevice *dev)
> > > > {
> > > > - if (CONFIG_IS_ENABLED(SYSRESET)) {
> > > > + if (CONFIG_IS_ENABLED(SYSRESET) && (gd->flags & GD_FLG_RELOC)) {
> > > > device_bind_driver(dev, "rk8xx_sysreset",
> > > >"rk8xx_sysreset", NULL);
> > > > }
> > > > --
> > > > 2.37.1
> > > >
> > >
> > > I think it is OK to avoid starting a device before relocation, or make
> > > that device do something different. I really don't like the binding
> > > being optional though...we have the 'u-boot,dm-pre-reloc' for that.
> >
> > So perhaps the flag should be dropped from rk8xx then.
> >
> > >
> > > But missing from your commit message is exactly what fails?
> >
> > The pmic is an i2c device, all i2c tranferss fail if initialized
> > pre-relocation. I supect it's the i2c bus that fails if initialized
> > before reloc - the regulatorss that share the i2c bus also report i2c
> > transfer failure.
>
> OK, I wonder why i2c fails? It works OK on the rockchip devices I'm
> familiar with, e.g. chromebooks.
It worksss fine here as well - so long as it is not initialized before
relocation.
Thanks
Michal
rk3399 TPL memory setup code triggers clock frequency limit assertion
Hello, when compiled with clock debug rk3399 cannot be booted because memory setup code triggers clock assertion: U-Boot TPL 2022.07-00038-g61e11a8e9f-dirty (Aug 07 2022 - 16:13:17) TPL PLL at ff76: fbdiv=50, refdiv=1, postdiv1=2, postdiv2=1, vco=120 khz, output=60 khz TPL PLL at ff760020: fbdiv=50, refdiv=1, postdiv1=2, postdiv2=1, vco=120 khz, output=60 khz TPL PLL at ff760080: fbdiv=99, refdiv=2, postdiv1=2, postdiv2=1, vco=1188000 khz, output=594000 khz TPL PLL at ff760060: fbdiv=64, refdiv=1, postdiv1=2, postdiv2=2, vco=1536000 khz, output=384000 khz TPL PLL at ff760040: fbdiv=12, refdiv=1, postdiv1=3, postdiv2=2, vco=288000 khz, output=48000 khz drivers/clk/rockchip/clk_rk3399.c:347: rkclk_set_pll: Assertion `vco_khz >= VCO_MIN_KHZ && vco_khz <= VCO_MAX_KHZ && output_khz >= OUTPUT_MIN_KHZ && output_khz <= OUTPUT_MAX_KHZ && div->fbdiv >= PLL_DIV_MIN && div->fbdiv <= PLL_DIV_MAX' failed.Channel 0: LPDDR4, 50MHz BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB Channel 1: LPDDR4, 50MHz BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB 256B stride TPL PLL at ff760040: fbdiv=50, refdiv=1, postdiv1=3, postdiv2=1, vco=120 khz, output=40 khz lpddr4_set_rate: change freq to 4 mhz 0, 1 TPL PLL at ff760040: fbdiv=100, refdiv=1, postdiv1=3, postdiv2=1, vco=240 khz, output=80 khz lpddr4_set_rate: change freq to 8 mhz 1, 0 Trying to boot from BOOTROM Returning to boot ROM... SPL PLL at ff76: fbdiv=50, refdiv=1, postdiv1=2, postdiv2=1, vco=120 khz, output=60 khz SPL PLL at ff760020: fbdiv=50, refdiv=1, postdiv1=2, postdiv2=1, vco=120 khz, output=60 khz SPL PLL at ff760080: fbdiv=99, refdiv=2, postdiv1=2, postdiv2=1, vco=1188000 khz, output=594000 khz SPL PLL at ff760060: fbdiv=64, refdiv=1, postdiv1=2, postdiv2=2, vco=1536000 khz, output=384000 khz U-Boot SPL 2022.07-00038-g61e11a8e9f-dirty (Aug 07 2022 - 16:13:17 +0200) mmc@fe32: Got clock clock-controller@ff76 76 Trying to boot from MMC2 NOTICE: BL31: v2.6(debug): NOTICE: BL31: Built : 14:50:40, Jul 1 2022 INFO:GICv3 with legacy support detected. INFO:ARM GICv3 driver initialized in EL3 INFO:Maximum SPI INTID supported: 287 INFO:plat_rockchip_pmu_init(1624): pd status 3e INFO:BL31: Initializing runtime services INFO:BL31: cortex_a53: CPU workaround for 855873 was applied WARNING: BL31: cortex_a53: CPU workaround for 1530924 was missing! INFO:BL31: Preparing for EL3 exit to normal world INFO:Entry point address = 0x20 INFO:SPSR = 0x3c9 Clearly the assertion is wrong at least for this PLL because the system boots with the assertion disarmed. Then again, it is not clear that the PLL is operated at this frequency at all - it is immediately changed to higher frequency when the memory type is detected. What would be a resonable way to make rk3399 bootable with clock debug enabled? Thanks Michal
Re: rk3399 TPL memory setup code triggers clock frequency limit assertion
On Sun, Aug 07, 2022 at 08:31:56PM +0530, Jagan Teki wrote: > On Sun, Aug 7, 2022 at 8:14 PM Michal Suchánek wrote: > > > > Hello, > > > > when compiled with clock debug rk3399 cannot be booted because memory > > setup code triggers clock assertion: > > > > U-Boot TPL 2022.07-00038-g61e11a8e9f-dirty (Aug 07 2022 - 16:13:17) > > TPL PLL at ff76: fbdiv=50, refdiv=1, postdiv1=2, postdiv2=1, > > vco=120 khz, output=60 khz > > TPL PLL at ff760020: fbdiv=50, refdiv=1, postdiv1=2, postdiv2=1, > > vco=120 khz, output=60 khz > > TPL PLL at ff760080: fbdiv=99, refdiv=2, postdiv1=2, postdiv2=1, > > vco=1188000 khz, output=594000 khz > > TPL PLL at ff760060: fbdiv=64, refdiv=1, postdiv1=2, postdiv2=2, > > vco=1536000 khz, output=384000 khz > > TPL PLL at ff760040: fbdiv=12, refdiv=1, postdiv1=3, postdiv2=2, vco=288000 > > khz, output=48000 khz > > drivers/clk/rockchip/clk_rk3399.c:347: rkclk_set_pll: Assertion `vco_khz >= > > VCO_MIN_KHZ && vco_khz <= VCO_MAX_KHZ && output_khz >= OUTPUT_MIN_KHZ && > > output_khz <= OUTPUT_MAX_KHZ && div->fbdiv >= PLL_DIV_MIN && div->fbdiv <= > > PLL_DIV_MAX' failed.Channel 0: LPDDR4, 50MHz > > Does it an external print for trigger mode? Do you mean the asserion? That's defined in lib/panic.c and include/log.h I patched assert() to not panic and only print the message. > > BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB > > Channel 1: LPDDR4, 50MHz > > BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB > > 256B stride > > TPL PLL at ff760040: fbdiv=50, refdiv=1, postdiv1=3, postdiv2=1, > > vco=120 khz, output=40 khz > > lpddr4_set_rate: change freq to 4 mhz 0, 1 > > TPL PLL at ff760040: fbdiv=100, refdiv=1, postdiv1=3, postdiv2=1, > > vco=240 khz, output=80 khz > > lpddr4_set_rate: change freq to 8 mhz 1, 0 > > Trying to boot from BOOTROM > > Returning to boot ROM... > > SPL PLL at ff76: fbdiv=50, refdiv=1, postdiv1=2, postdiv2=1, > > vco=120 khz, output=60 khz > > SPL PLL at ff760020: fbdiv=50, refdiv=1, postdiv1=2, postdiv2=1, > > vco=120 khz, output=60 khz > > SPL PLL at ff760080: fbdiv=99, refdiv=2, postdiv1=2, postdiv2=1, > > vco=1188000 khz, output=594000 khz > > SPL PLL at ff760060: fbdiv=64, refdiv=1, postdiv1=2, postdiv2=2, > > vco=1536000 khz, output=384000 khz > > Look good to me at least on PLL detections on respective clocks. Yes, I don't obeserve anything that is defeinitely a clock problem, I just cannot boot with clock debug enabled. > > > > U-Boot SPL 2022.07-00038-g61e11a8e9f-dirty (Aug 07 2022 - 16:13:17 +0200) > > mmc@fe32: Got clock clock-controller@ff76 76 > > Trying to boot from MMC2 > > NOTICE: BL31: v2.6(debug): > > NOTICE: BL31: Built : 14:50:40, Jul 1 2022 > > INFO:GICv3 with legacy support detected. > > INFO:ARM GICv3 driver initialized in EL3 > > INFO:Maximum SPI INTID supported: 287 > > INFO:plat_rockchip_pmu_init(1624): pd status 3e > > INFO:BL31: Initializing runtime services > > INFO:BL31: cortex_a53: CPU workaround for 855873 was applied > > WARNING: BL31: cortex_a53: CPU workaround for 1530924 was missing! > > INFO:BL31: Preparing for EL3 exit to normal world > > INFO:Entry point address = 0x20 > > INFO:SPSR = 0x3c9 > > Maybe TF-A? What with TF-A? Yes, it's used but the problem happens before it's loaded. > Here is the output when we s/debug/printf/ for your reference. > > U-Boot TPL 2022.10-rc1-00077-g23c0174967-dirty (Aug 07 2022 - 20:26:36) > PLL at ff76: fbdiv=50, refdiv=1, postdiv1=2, postdiv2=1, > vco=120 khz, output=60 khz > PLL at ff760020: fbdiv=50, refdiv=1, postdiv1=2, postdiv2=1, > vco=120 khz, output=60 khz > PLL at ff760080: fbdiv=99, refdiv=2, postdiv1=2, postdiv2=1, > vco=1188000 khz, output=594000 khz > PLL at ff760060: fbdiv=64, refdiv=1, postdiv1=2, postdiv2=2, > vco=1536000 khz, output=384000 khz > PLL at ff760040: fbdiv=12, refdiv=1, postdiv1=3, postdiv2=2, > vco=288000 khz, output=48000 khz Which looks exactly the same, except with s/debug/printf/ the assert is not enabled, that only happens with DEBUG defined. Thanks Michal
Re: [SPAM] rk3399 TPL memory setup code triggers clock frequency limit assertion
On Mon, Aug 08, 2022 at 04:28:33PM +0200, Xavier Drudis Ferran wrote: > El Sun, Aug 07, 2022 at 04:44:04PM +0200, Michal Suchánek deia: > > Hello, > > > > when compiled with clock debug rk3399 cannot be booted because memory > > setup code triggers clock assertion: > > > > U-Boot TPL 2022.07-00038-g61e11a8e9f-dirty (Aug 07 2022 - 16:13:17) > > TPL PLL at ff76: fbdiv=50, refdiv=1, postdiv1=2, postdiv2=1, > > vco=120 khz, output=60 khz > > TPL PLL at ff760020: fbdiv=50, refdiv=1, postdiv1=2, postdiv2=1, > > vco=120 khz, output=60 khz > > TPL PLL at ff760080: fbdiv=99, refdiv=2, postdiv1=2, postdiv2=1, > > vco=1188000 khz, output=594000 khz > > TPL PLL at ff760060: fbdiv=64, refdiv=1, postdiv1=2, postdiv2=2, > > vco=1536000 khz, output=384000 khz > > TPL PLL at ff760040: fbdiv=12, refdiv=1, postdiv1=3, postdiv2=2, vco=288000 > > khz, output=48000 khz > > drivers/clk/rockchip/clk_rk3399.c:347: rkclk_set_pll: Assertion `vco_khz >= > > VCO_MIN_KHZ && vco_khz <= VCO_MAX_KHZ && output_khz >= OUTPUT_MIN_KHZ && > > output_khz <= OUTPUT_MAX_KHZ && div->fbdiv >= PLL_DIV_MIN && div->fbdiv <= > > PLL_DIV_MAX' failed.Channel 0: LPDDR4, 50MHz > > Sorry, I don't have time now. But It might be related to > > https://patchwork.ozlabs.org/project/uboot/patch/20220716103144.GA2167@begut/ > > Apparently this clock is wrong but nobody finds any consequence of it being > wrong. > If one asks for a 50MHz clock and gets a 48MHz clockthings might work anyway, > but > it's nice that at least when one asks to be told of problems one is told. Yes, that's exactly what I was looking for. It resolves the discrepancy between the asssert and the set clock by adjusting the clock settings. Thanks Michal U-Boot TPL 2022.07-00044-gc1e2523e7d-dirty (Aug 08 2022 - 18:10:27) TPL PLL at ff76: fbdiv=50, refdiv=1, postdiv1=2, postdiv2=1, vco=120 khz, output=60 khz TPL PLL at ff760020: fbdiv=50, refdiv=1, postdiv1=2, postdiv2=1, vco=120 khz, output=60 khz TPL PLL at ff760080: fbdiv=99, refdiv=2, postdiv1=2, postdiv2=1, vco=1188000 khz, output=594000 khz TPL PLL at ff760060: fbdiv=64, refdiv=1, postdiv1=2, postdiv2=2, vco=1536000 khz, output=384000 khz TPL PLL at ff760040: fbdiv=75, refdiv=2, postdiv1=3, postdiv2=6, vco=90 khz, output=5 khz rk3399_clk_set_rate: clk clock-controller@ff76 170 rate 5000 -> 5000 Channel 0: LPDDR4, 50MHz BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB Channel 1: LPDDR4, 50MHz BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB 256B stride TPL PLL at ff760040: fbdiv=50, refdiv=1, postdiv1=3, postdiv2=1, vco=120 khz, output=40 khz rk3399_clk_set_rate: clk clock-controller@ff76 170 rate 4 -> 4 lpddr4_set_rate: change freq to 4 mhz 0, 1 TPL PLL at ff760040: fbdiv=100, refdiv=1, postdiv1=3, postdiv2=1, vco=240 khz, output=80 khz rk3399_clk_set_rate: clk clock-controller@ff76 170 rate 8 -> 8 lpddr4_set_rate: change freq to 8 mhz 1, 0 Trying to boot from BOOTROM Returning to boot ROM... SPL PLL at ff76: fbdiv=50, refdiv=1, postdiv1=2, postdiv2=1, vco=120 khz, output=60 khz SPL PLL at ff760020: fbdiv=50, refdiv=1, postdiv1=2, postdiv2=1, vco=120 khz, output=60 khz SPL PLL at ff760080: fbdiv=99, refdiv=2, postdiv1=2, postdiv2=1, vco=1188000 khz, output=594000 khz SPL PLL at ff760060: fbdiv=64, refdiv=1, postdiv1=2, postdiv2=2, vco=1536000 khz, output=384000 khz rk3399_clk_get_rate: clk clock-controller@ff76 83 U-Boot SPL 2022.07-00044-gc1e2523e7d-dirty (Aug 08 2022 - 18:10:27 +0200)
Re: [PATCH] arm: rockchip: rk3399: Program PLL clock for DDR at 50 MHz in documented range
On Sat, Jul 16, 2022 at 12:31:45PM +0200, Xavier Drudis Ferran wrote:
> The original code set up the DDR clock to 48 MHz, not 50MHz as
> requested, and did it in a way that didn't satisfy the Application
> Notes in RK3399 TRM [1]. 2.9.2.B says:
>
>PLL frequency range requirement
>[...]
>FOUTVCO: 800MHz to 3.2GHz
>
> 2.9.2.A :
>PLL output frequency configuration
>[...]
>FOUTVCO = FREF / REFDIV * FBDIV
>FOUTPOSTDIV = FOUTVCO / POSTDIV1 / POSTDIV2
>
> FREF = 24 MHz
>
> The original code gives FOUTVCO: 24MHz/1 * 12 = 288MHz < 800MHz
> And the resulting FOUTPOSTDIV is 288MHz / 3 / 2 = 48MHz
> but the requested frequency was 50MHz
>
> Note:
> 2.7.2 Detail Register Description
> PMUCRU_PPLL_CON0 says
>
>fbdiv
>Feedback Divide Value
>Valid divider settings are:
>[16, 3200] in integer mode
>
> So .fbdiv = 12 wouldn't be right. But 2.9.2.C says:
>
>PLL setting consideration
>[...]
>The following settings are valid for FBDIV:
>DSMPD=1 (Integer Mode):
>12,13,14,16-4095 (practical value is limited to 3200, 2400, or 1600
>(FVCOMAX / FREFMIN))
>[...]
>
> So .fbdiv = 12 would be right.
>
> In any case FOUTVCO is still wrong. I thank YouMin Chen for
> confirmation and explanation.
>
> Despite documentation, I don't seem to be able to reproduce a
> practical problem with the wrong FOUTVCO. When I initially found it I
> thought some problems with detecting the RAM capacity in my Rock Pi 4B
> could be related to it and my patch seemed to help. But since I'm no
> longer able to reproduce the issue, it works with or without this
> patch. And meanwhile a patch[2] by Lee Jones and YouMin Chen addresses
> this issue. Btw, shouldn't that be commited?
>
> So this patches solves no visible problem. Yet, to prevent future
> problems, I think it'd be best to stick to spec.
>
> An alternative to this patch could be
>
> {.refdiv = 1, .fbdiv = 75, .postdiv1 = 6, .postdiv2 = 6};
>
> This would theoretically consume more power and yield less jitter,
> according to 2.9.2.C :
>
>PLL setting consideration
>[...]
>For lowest power operation, the minimum VCO and FREF frequencies
>should be used. For minimum jitter operation, the highest VCO and
>FREF frequencies should be used.
>[...]
>
> But I haven't tried it because I don't think it matters much. 50MHz
> for DDR is only shortly used by TPL at RAM init. Normal operation is
> at 800MHz. Maybe it's better to use less power until later when more
> complex software can control batteries or charging or whatever ?
>
> Cc: Simon Glass
> Cc: Philipp Tomsich
> Cc: Kever Yang
> Cc: Lukasz Majewski
> Cc: Sean Anderson
>
> Link: [1] https://www.rockchip.fr/Rockchip%20RK3399%20TRM%20V1.4%20Part1.pdf
>
> Link: [2] https://patchwork.ozlabs.org/project/uboot/list/?series=305766
>
> Signed-off-by: Xavier Drudis Ferran
The incorrect clock settings trigger an assert and prevent the board
from booting when clock debugging is enabled.
Fix works for me on Pinebook Pro.
Thanks
Michal
Tested-by: Michal Suchánek
> ---
> drivers/clk/rockchip/clk_rk3399.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/clk/rockchip/clk_rk3399.c
> b/drivers/clk/rockchip/clk_rk3399.c
> index 7d31a9f22a..4762462b04 100644
> --- a/drivers/clk/rockchip/clk_rk3399.c
> +++ b/drivers/clk/rockchip/clk_rk3399.c
> @@ -840,7 +840,7 @@ static ulong rk3399_ddr_set_clk(struct rockchip_cru *cru,
> switch (set_rate) {
> case 50 * MHz:
> dpll_cfg = (struct pll_div)
> - {.refdiv = 1, .fbdiv = 12, .postdiv1 = 3, .postdiv2 = 2};
> + {.refdiv = 2, .fbdiv = 75, .postdiv1 = 3, .postdiv2 = 6};
> break;
> case 200 * MHz:
> dpll_cfg = (struct pll_div)
> --
> 2.20.1
>
Re: [U-Boot] [PATCH 3/8] usb_kdb: only process events succesfully received
On Tue, 2 Jul 2019 13:58:30 +0200 Marek Vasut wrote: > On 7/1/19 5:56 PM, Michal Suchanek wrote: > > Causes unbound key repeat on error otherwise. > > > > Signed-off-by: Michal Suchanek > > --- > > common/usb_kbd.c | 7 +++ > > 1 file changed, 3 insertions(+), 4 deletions(-) > > > > diff --git a/common/usb_kbd.c b/common/usb_kbd.c > > index cc99c6be0720..948f9fd68490 100644 > > --- a/common/usb_kbd.c > > +++ b/common/usb_kbd.c > > @@ -339,10 +339,9 @@ static inline void usb_kbd_poll_for_event(struct > > usb_device *dev) > > struct usb_kbd_pdata *data = dev->privptr; > > > > /* Submit a interrupt transfer request */ > > - usb_submit_int_msg(dev, data->intpipe, &data->new[0], data->intpktsize, > > - data->intinterval); > > - > > - usb_kbd_irq_worker(dev); > > + if (!usb_submit_int_msg(dev, data->intpipe, &data->new[0], > > Shouldn't you propagate return value from this function ? It can return > ENOTSUPP. > If it did then probing keyboard would fail and we would not get here. Thanks Michal ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 6/8] usb: add usb_submit_int_msg_nonblock
On Tue, 2 Jul 2019 13:59:49 +0200
Marek Vasut wrote:
> On 7/1/19 5:56 PM, Michal Suchanek wrote:
> > Signed-off-by: Michal Suchanek
> > ---
> > common/usb.c | 9 +
> > include/usb.h | 2 ++
> > 2 files changed, 11 insertions(+)
> >
> > diff --git a/common/usb.c b/common/usb.c
> > index 3ae71c98aaf4..d8302d39a91a 100644
> > --- a/common/usb.c
> > +++ b/common/usb.c
> > @@ -200,6 +200,15 @@ int usb_submit_int_msg(struct usb_device *dev,
> > unsigned long pipe,
> > return submit_int_msg(dev, pipe, buffer, transfer_len, interval, false);
> > }
> >
> > +/*
> > + * submits an Interrupt Message without retry
> > + */
> > +int usb_submit_int_msg_nonblock(struct usb_device *dev, unsigned long pipe,
> > + void *buffer, int transfer_len, int interval)
> > +{
> > + return submit_int_msg(dev, pipe, buffer, transfer_len, interval, true);
> > +}
>
> Is this wrapper really necessary ?
>
Avoids changing other users of the code. Not that there are that many,
anyway.
Thanks
Michal
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/8] usb_kdb: only process events succesfully received
On Tue, 2 Jul 2019 15:11:07 +0200 Marek Vasut wrote: > On 7/2/19 3:04 PM, Michal Suchánek wrote: > > On Tue, 2 Jul 2019 13:58:30 +0200 > > Marek Vasut wrote: > > > >> On 7/1/19 5:56 PM, Michal Suchanek wrote: > >>> Causes unbound key repeat on error otherwise. > >>> > >>> Signed-off-by: Michal Suchanek > >>> --- > >>> common/usb_kbd.c | 7 +++ > >>> 1 file changed, 3 insertions(+), 4 deletions(-) > >>> > >>> diff --git a/common/usb_kbd.c b/common/usb_kbd.c > >>> index cc99c6be0720..948f9fd68490 100644 > >>> --- a/common/usb_kbd.c > >>> +++ b/common/usb_kbd.c > >>> @@ -339,10 +339,9 @@ static inline void usb_kbd_poll_for_event(struct > >>> usb_device *dev) > >>> struct usb_kbd_pdata *data = dev->privptr; > >>> > >>> /* Submit a interrupt transfer request */ > >>> - usb_submit_int_msg(dev, data->intpipe, &data->new[0], data->intpktsize, > >>> -data->intinterval); > >>> - > >>> - usb_kbd_irq_worker(dev); > >>> + if (!usb_submit_int_msg(dev, data->intpipe, &data->new[0], > >> > >> Shouldn't you propagate return value from this function ? It can return > >> ENOTSUPP. > >> > > > > If it did then probing keyboard would fail and we would not get here. > > So there is no chance this function could return an error here, ever ? > E.g. what if it's implemented and someone yanks the keyboard cable out > just at the right time ? It returns errors all the time with dwc2. That's why we need to check for the error condition. We should not get here if probing the keyboard failed, though. So if the function is not supported we will not get here. Anyway, if it's not supported or the keyboard is missing it by definition cannot provide useful result so we should not process it. Thanks Michal ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 6/8] usb: add usb_submit_int_msg_nonblock
On Tue, 2 Jul 2019 22:16:02 +0800
Bin Meng wrote:
> Hi Michal,
>
> On Tue, Jul 2, 2019 at 10:14 PM Michal Suchánek wrote:
> >
> > On Tue, 2 Jul 2019 13:59:49 +0200
> > Marek Vasut wrote:
> >
> > > On 7/1/19 5:56 PM, Michal Suchanek wrote:
> > > > Signed-off-by: Michal Suchanek
> > > > ---
> > > > common/usb.c | 9 +
> > > > include/usb.h | 2 ++
> > > > 2 files changed, 11 insertions(+)
> > > >
> > > > diff --git a/common/usb.c b/common/usb.c
> > > > index 3ae71c98aaf4..d8302d39a91a 100644
> > > > --- a/common/usb.c
> > > > +++ b/common/usb.c
> > > > @@ -200,6 +200,15 @@ int usb_submit_int_msg(struct usb_device *dev,
> > > > unsigned long pipe,
> > > > return submit_int_msg(dev, pipe, buffer, transfer_len, interval,
> > > > false);
> > > > }
> > > >
> > > > +/*
> > > > + * submits an Interrupt Message without retry
> > > > + */
> > > > +int usb_submit_int_msg_nonblock(struct usb_device *dev, unsigned long
> > > > pipe,
> > > > + void *buffer, int transfer_len, int interval)
> > > > +{
> > > > + return submit_int_msg(dev, pipe, buffer, transfer_len, interval,
> > > > true);
> > > > +}
> > >
> > > Is this wrapper really necessary ?
> > >
> >
> > Avoids changing other users of the code. Not that there are that many,
> > anyway.
>
> Then I wonder why not change your codes to call submit_int_msg() instead?
>
Why do we have usb_submit_int_msg in the first place?
Thanks
Michal
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 6/8] usb: add usb_submit_int_msg_nonblock
On Tue, 2 Jul 2019 22:29:42 +0800
Bin Meng wrote:
> Hi Michal,
>
> On Tue, Jul 2, 2019 at 10:25 PM Michal Suchánek wrote:
> >
> > On Tue, 2 Jul 2019 22:16:02 +0800
> > Bin Meng wrote:
> >
> > > Hi Michal,
> > >
> > > On Tue, Jul 2, 2019 at 10:14 PM Michal Suchánek
> > > wrote:
> > > >
> > > > On Tue, 2 Jul 2019 13:59:49 +0200
> > > > Marek Vasut wrote:
> > > >
> > > > > On 7/1/19 5:56 PM, Michal Suchanek wrote:
> > > > > > Signed-off-by: Michal Suchanek
> > > > > > ---
> > > > > > common/usb.c | 9 +
> > > > > > include/usb.h | 2 ++
> > > > > > 2 files changed, 11 insertions(+)
> > > > > >
> > > > > > diff --git a/common/usb.c b/common/usb.c
> > > > > > index 3ae71c98aaf4..d8302d39a91a 100644
> > > > > > --- a/common/usb.c
> > > > > > +++ b/common/usb.c
> > > > > > @@ -200,6 +200,15 @@ int usb_submit_int_msg(struct usb_device *dev,
> > > > > > unsigned long pipe,
> > > > > > return submit_int_msg(dev, pipe, buffer, transfer_len,
> > > > > > interval, false);
> > > > > > }
> > > > > >
> > > > > > +/*
> > > > > > + * submits an Interrupt Message without retry
> > > > > > + */
> > > > > > +int usb_submit_int_msg_nonblock(struct usb_device *dev, unsigned
> > > > > > long pipe,
> > > > > > + void *buffer, int transfer_len, int interval)
> > > > > > +{
> > > > > > + return submit_int_msg(dev, pipe, buffer, transfer_len,
> > > > > > interval, true);
> > > > > > +}
> > > > >
> > > > > Is this wrapper really necessary ?
> > > > >
> > > >
> > > > Avoids changing other users of the code. Not that there are that many,
> > > > anyway.
> > >
> > > Then I wonder why not change your codes to call submit_int_msg() instead?
> > >
> > Why do we have usb_submit_int_msg in the first place?
>
> I am happy to remove that. A patch is welcome. :)
>
So the answer is we have wrappers for USB messages, and while
submit_int_msg is trivial others are not. To keep reasonable interface
all messages should be wrapped.
Thanks
Michal
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 6/8] usb: add usb_submit_int_msg_nonblock
On Tue, 2 Jul 2019 23:11:01 +0800
Bin Meng wrote:
> Hi Michal,
>
> On Tue, Jul 2, 2019 at 10:58 PM Michal Suchánek wrote:
> >
> > On Tue, 2 Jul 2019 22:29:42 +0800
> > Bin Meng wrote:
> >
> > > Hi Michal,
> > >
> > > On Tue, Jul 2, 2019 at 10:25 PM Michal Suchánek
> > > wrote:
> > > >
> > > > On Tue, 2 Jul 2019 22:16:02 +0800
> > > > Bin Meng wrote:
> > > >
> > > > > Hi Michal,
> > > > >
> > > > > On Tue, Jul 2, 2019 at 10:14 PM Michal Suchánek
> > > > > wrote:
> > > > > >
> > > > > > On Tue, 2 Jul 2019 13:59:49 +0200
> > > > > > Marek Vasut wrote:
> > > > > >
> > > > > > > On 7/1/19 5:56 PM, Michal Suchanek wrote:
> > > > > > > > Signed-off-by: Michal Suchanek
> > > > > > > > ---
> > > > > > > > common/usb.c | 9 +
> > > > > > > > include/usb.h | 2 ++
> > > > > > > > 2 files changed, 11 insertions(+)
> > > > > > > >
> > > > > > > > diff --git a/common/usb.c b/common/usb.c
> > > > > > > > index 3ae71c98aaf4..d8302d39a91a 100644
> > > > > > > > --- a/common/usb.c
> > > > > > > > +++ b/common/usb.c
> > > > > > > > @@ -200,6 +200,15 @@ int usb_submit_int_msg(struct usb_device
> > > > > > > > *dev, unsigned long pipe,
> > > > > > > > return submit_int_msg(dev, pipe, buffer, transfer_len,
> > > > > > > > interval, false);
> > > > > > > > }
> > > > > > > >
> > > > > > > > +/*
> > > > > > > > + * submits an Interrupt Message without retry
> > > > > > > > + */
> > > > > > > > +int usb_submit_int_msg_nonblock(struct usb_device *dev,
> > > > > > > > unsigned long pipe,
> > > > > > > > + void *buffer, int transfer_len, int
> > > > > > > > interval)
> > > > > > > > +{
> > > > > > > > + return submit_int_msg(dev, pipe, buffer, transfer_len,
> > > > > > > > interval, true);
> > > > > > > > +}
> > > > > > >
> > > > > > > Is this wrapper really necessary ?
> > > > > > >
> > > > > >
> > > > > > Avoids changing other users of the code. Not that there are that
> > > > > > many,
> > > > > > anyway.
> > > > >
> > > > > Then I wonder why not change your codes to call submit_int_msg()
> > > > > instead?
> > > > >
> > > > Why do we have usb_submit_int_msg in the first place?
> > >
> > > I am happy to remove that. A patch is welcome. :)
> > >
> >
> > So the answer is we have wrappers for USB messages, and while
> > submit_int_msg is trivial others are not. To keep reasonable interface
> > all messages should be wrapped.
>
> I don't see usb_submit_control_msg() or usb_submit_bulk_msg(), so I
> think we should remove usb_submit_int_msg() and just leave
> submit_int_msg() for drivers to call.
There is no _submit_ in those. See include/usb.h
Thanks
Michal
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 6/8] usb: add usb_submit_int_msg_nonblock
On Tue, 2 Jul 2019 23:39:42 +0800
Bin Meng wrote:
> On Tue, Jul 2, 2019 at 11:30 PM Michal Suchánek wrote:
> >
> > On Tue, 2 Jul 2019 23:11:01 +0800
> > Bin Meng wrote:
> >
> > > Hi Michal,
> > >
> > > On Tue, Jul 2, 2019 at 10:58 PM Michal Suchánek
> > > wrote:
> > > >
> > > > On Tue, 2 Jul 2019 22:29:42 +0800
> > > > Bin Meng wrote:
> > > >
> > > > > Hi Michal,
> > > > >
> > > > > On Tue, Jul 2, 2019 at 10:25 PM Michal Suchánek
> > > > > wrote:
> > > > > >
> > > > > > On Tue, 2 Jul 2019 22:16:02 +0800
> > > > > > Bin Meng wrote:
> > > > > >
> > > > > > > Hi Michal,
> > > > > > >
> > > > > > > On Tue, Jul 2, 2019 at 10:14 PM Michal Suchánek
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > On Tue, 2 Jul 2019 13:59:49 +0200
> > > > > > > > Marek Vasut wrote:
> > > > > > > >
> > > > > > > > > On 7/1/19 5:56 PM, Michal Suchanek wrote:
> > > > > > > > > > Signed-off-by: Michal Suchanek
> > > > > > > > > > ---
> > > > > > > > > > common/usb.c | 9 +
> > > > > > > > > > include/usb.h | 2 ++
> > > > > > > > > > 2 files changed, 11 insertions(+)
> > > > > > > > > >
> > > > > > > > > > diff --git a/common/usb.c b/common/usb.c
> > > > > > > > > > index 3ae71c98aaf4..d8302d39a91a 100644
> > > > > > > > > > --- a/common/usb.c
> > > > > > > > > > +++ b/common/usb.c
> > > > > > > > > > @@ -200,6 +200,15 @@ int usb_submit_int_msg(struct
> > > > > > > > > > usb_device *dev, unsigned long pipe,
> > > > > > > > > > return submit_int_msg(dev, pipe, buffer, transfer_len,
> > > > > > > > > > interval, false);
> > > > > > > > > > }
> > > > > > > > > >
> > > > > > > > > > +/*
> > > > > > > > > > + * submits an Interrupt Message without retry
> > > > > > > > > > + */
> > > > > > > > > > +int usb_submit_int_msg_nonblock(struct usb_device *dev,
> > > > > > > > > > unsigned long pipe,
> > > > > > > > > > + void *buffer, int transfer_len, int
> > > > > > > > > > interval)
> > > > > > > > > > +{
> > > > > > > > > > + return submit_int_msg(dev, pipe, buffer, transfer_len,
> > > > > > > > > > interval, true);
> > > > > > > > > > +}
> > > > > > > > >
> > > > > > > > > Is this wrapper really necessary ?
> > > > > > > > >
> > > > > > > >
> > > > > > > > Avoids changing other users of the code. Not that there are
> > > > > > > > that many,
> > > > > > > > anyway.
> > > > > > >
> > > > > > > Then I wonder why not change your codes to call submit_int_msg()
> > > > > > > instead?
> > > > > > >
> > > > > > Why do we have usb_submit_int_msg in the first place?
> > > > >
> > > > > I am happy to remove that. A patch is welcome. :)
> > > > >
> > > >
> > > > So the answer is we have wrappers for USB messages, and while
> > > > submit_int_msg is trivial others are not. To keep reasonable interface
> > > > all messages should be wrapped.
> > >
> > > I don't see usb_submit_control_msg() or usb_submit_bulk_msg(), so I
> > > think we should remove usb_submit_int_msg() and just leave
> > > submit_int_msg() for drivers to call.
> >
> > There is no _submit_ in those. See include/usb.h
> >
>
> OK, so we should just rename usb_submit_int_msg() to usb_int_msg() and
> everything is consistent, no?
>
Yes, looks like the _submit in usb_submit_int_msg is superfluous.
Thanks
Michal
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/8] usb_kdb: only process events succesfully received
On Tue, 2 Jul 2019 18:58:54 +0200 Marek Vasut wrote: > On 7/2/19 4:22 PM, Michal Suchánek wrote: > > On Tue, 2 Jul 2019 15:11:07 +0200 > > Marek Vasut wrote: > > > >> On 7/2/19 3:04 PM, Michal Suchánek wrote: > >>> On Tue, 2 Jul 2019 13:58:30 +0200 > >>> Marek Vasut wrote: > >>> > >>>> On 7/1/19 5:56 PM, Michal Suchanek wrote: > >>>>> Causes unbound key repeat on error otherwise. > >>>>> > >>>>> Signed-off-by: Michal Suchanek > >>>>> --- > >>>>> common/usb_kbd.c | 7 +++ > >>>>> 1 file changed, 3 insertions(+), 4 deletions(-) > >>>>> > >>>>> diff --git a/common/usb_kbd.c b/common/usb_kbd.c > >>>>> index cc99c6be0720..948f9fd68490 100644 > >>>>> --- a/common/usb_kbd.c > >>>>> +++ b/common/usb_kbd.c > >>>>> @@ -339,10 +339,9 @@ static inline void usb_kbd_poll_for_event(struct > >>>>> usb_device *dev) > >>>>> struct usb_kbd_pdata *data = dev->privptr; > >>>>> > >>>>> /* Submit a interrupt transfer request */ > >>>>> - usb_submit_int_msg(dev, data->intpipe, &data->new[0], > >>>>> data->intpktsize, > >>>>> - data->intinterval); > >>>>> - > >>>>> - usb_kbd_irq_worker(dev); > >>>>> + if (!usb_submit_int_msg(dev, data->intpipe, &data->new[0], > >>>> > >>>> Shouldn't you propagate return value from this function ? It can return > >>>> ENOTSUPP. > >>>> > >>> > >>> If it did then probing keyboard would fail and we would not get here. > >> > >> So there is no chance this function could return an error here, ever ? > >> E.g. what if it's implemented and someone yanks the keyboard cable out > >> just at the right time ? > > > > It returns errors all the time with dwc2. That's why we need to check > > for the error condition. We should not get here if probing the keyboard > > failed, though. So if the function is not supported we will not get > > here. Anyway, if it's not supported or the keyboard is missing it by > > definition cannot provide useful result so we should not process it. > > Except you start ignoring the error value from e.g. malfunctioning > keyboard here, instead of propagating it, correct ? It was never propagated to start with. The return value was not checked at all. What I do here is check the return value and not process the data on error whatever it contains (like the keypress returned last time valid data was received). Thanks Michal ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/8] usb_kdb: only process events succesfully received
On Tue, 2 Jul 2019 19:50:05 +0200 Michal Suchánek wrote: > On Tue, 2 Jul 2019 18:58:54 +0200 > Marek Vasut wrote: > > > On 7/2/19 4:22 PM, Michal Suchánek wrote: > > > On Tue, 2 Jul 2019 15:11:07 +0200 > > > Marek Vasut wrote: > > > > > >> On 7/2/19 3:04 PM, Michal Suchánek wrote: > > >>> On Tue, 2 Jul 2019 13:58:30 +0200 > > >>> Marek Vasut wrote: > > >>> > > >>>> On 7/1/19 5:56 PM, Michal Suchanek wrote: > > >>>>> Causes unbound key repeat on error otherwise. > > >>>>> > > >>>>> Signed-off-by: Michal Suchanek > > >>>>> --- > > >>>>> common/usb_kbd.c | 7 +++ > > >>>>> 1 file changed, 3 insertions(+), 4 deletions(-) > > >>>>> > > >>>>> diff --git a/common/usb_kbd.c b/common/usb_kbd.c > > >>>>> index cc99c6be0720..948f9fd68490 100644 > > >>>>> --- a/common/usb_kbd.c > > >>>>> +++ b/common/usb_kbd.c > > >>>>> @@ -339,10 +339,9 @@ static inline void usb_kbd_poll_for_event(struct > > >>>>> usb_device *dev) > > >>>>> struct usb_kbd_pdata *data = dev->privptr; > > >>>>> > > >>>>> /* Submit a interrupt transfer request */ > > >>>>> - usb_submit_int_msg(dev, data->intpipe, &data->new[0], > > >>>>> data->intpktsize, > > >>>>> -data->intinterval); > > >>>>> - > > >>>>> - usb_kbd_irq_worker(dev); > > >>>>> + if (!usb_submit_int_msg(dev, data->intpipe, &data->new[0], > > >>>>> > > >>>> > > >>>> Shouldn't you propagate return value from this function ? It can return > > >>>> ENOTSUPP. > > >>>> > > >>> > > >>> If it did then probing keyboard would fail and we would not get here. > > >>> > > >> > > >> So there is no chance this function could return an error here, ever ? > > >> E.g. what if it's implemented and someone yanks the keyboard cable out > > >> just at the right time ? > > > > > > It returns errors all the time with dwc2. That's why we need to check > > > for the error condition. We should not get here if probing the keyboard > > > failed, though. So if the function is not supported we will not get > > > here. Anyway, if it's not supported or the keyboard is missing it by > > > definition cannot provide useful result so we should not process it. > > > > Except you start ignoring the error value from e.g. malfunctioning > > keyboard here, instead of propagating it, correct ? > > It was never propagated to start with. The return value was not checked > at all. What I do here is check the return value and not process the > data on error whatever it contains (like the keypress returned last > time valid data was received). Maybe the error here is using usb_kbd_irq_worker rather than usb_kbd_irq which checks some status before calling usb_kbd_irq_worker. Nonetheless, checking the return value from usb_submit_int_msg works for me. Thanks Michal ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/8] usb_kdb: only process events succesfully received
On Tue, 2 Jul 2019 20:38:27 +0200 Marek Vasut wrote: > On 7/2/19 7:50 PM, Michal Suchánek wrote: > > On Tue, 2 Jul 2019 18:58:54 +0200 > > Marek Vasut wrote: > > > >> On 7/2/19 4:22 PM, Michal Suchánek wrote: > >>> On Tue, 2 Jul 2019 15:11:07 +0200 > >>> Marek Vasut wrote: > >>> > >>>> On 7/2/19 3:04 PM, Michal Suchánek wrote: > >>>>> On Tue, 2 Jul 2019 13:58:30 +0200 > >>>>> Marek Vasut wrote: > >>>>> > >>>>>> On 7/1/19 5:56 PM, Michal Suchanek wrote: > >>>>>>> Causes unbound key repeat on error otherwise. > >>>>>>> > >>>>>>> Signed-off-by: Michal Suchanek > >>>>>>> --- > >>>>>>> common/usb_kbd.c | 7 +++ > >>>>>>> 1 file changed, 3 insertions(+), 4 deletions(-) > >>>>>>> > >>>>>>> diff --git a/common/usb_kbd.c b/common/usb_kbd.c > >>>>>>> index cc99c6be0720..948f9fd68490 100644 > >>>>>>> --- a/common/usb_kbd.c > >>>>>>> +++ b/common/usb_kbd.c > >>>>>>> @@ -339,10 +339,9 @@ static inline void usb_kbd_poll_for_event(struct > >>>>>>> usb_device *dev) > >>>>>>> struct usb_kbd_pdata *data = dev->privptr; > >>>>>>> > >>>>>>> /* Submit a interrupt transfer request */ > >>>>>>> - usb_submit_int_msg(dev, data->intpipe, &data->new[0], > >>>>>>> data->intpktsize, > >>>>>>> -data->intinterval); > >>>>>>> - > >>>>>>> - usb_kbd_irq_worker(dev); > >>>>>>> + if (!usb_submit_int_msg(dev, data->intpipe, &data->new[0], > >>>>>>> > >>>>>> > >>>>>> Shouldn't you propagate return value from this function ? It can return > >>>>>> ENOTSUPP. > >>>>>> > >>>>> > >>>>> If it did then probing keyboard would fail and we would not get here. > >>>>> > >>>> > >>>> So there is no chance this function could return an error here, ever ? > >>>> E.g. what if it's implemented and someone yanks the keyboard cable out > >>>> just at the right time ? > >>> > >>> It returns errors all the time with dwc2. That's why we need to check > >>> for the error condition. We should not get here if probing the keyboard > >>> failed, though. So if the function is not supported we will not get > >>> here. Anyway, if it's not supported or the keyboard is missing it by > >>> definition cannot provide useful result so we should not process it. > >> > >> Except you start ignoring the error value from e.g. malfunctioning > >> keyboard here, instead of propagating it, correct ? > > > > It was never propagated to start with. The return value was not checked > > at all. What I do here is check the return value and not process the > > data on error whatever it contains (like the keypress returned last > > time valid data was received). > > I can see a patch which checks usb_kbd_poll_for_event() return value. > Can you add one ? What for? Apparently the keypress is processed in usb_kbd_irq_worker. So checking the return value is needed to decide if the worker should run, and is not particularly useful outside usb_kbd_poll_for_event. We could signal a getc() failure but do we have any code handling getc() failures? Thanks Michal ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/9] usb: sl811-hcd: return -ENOTSUPP from unimplemented submit_int_msg
On Tue, 2 Jul 2019 20:41:04 +0200 Marek Vasut wrote: > On 7/2/19 7:55 PM, Michal Suchanek wrote: > > Commit message is still missing ... > > > Signed-off-by: Michal Suchanek > [...] It says "usb: sl811-hcd: return -ENOTSUPP from unimplemented submit_int_msg" Thanks Michal ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/9] usb_kdb: only process events succesfully received
On Wed, 3 Jul 2019 09:37:42 +0800 Bin Meng wrote: > Hi Michal, > > On Wed, Jul 3, 2019 at 1:57 AM Michal Suchanek wrote: > > > > On error the data buffer does not contain valid data so do not submit it > > for processing. Usually it will contain the last data recieved so the > > last pressed key will be repeated indefinitely on device failure. > > > > Signed-off-by: Michal Suchanek > > --- > > v2: fix indentation > > --- > > common/usb_kbd.c | 7 +++ > > 1 file changed, 3 insertions(+), 4 deletions(-) > > > > diff --git a/common/usb_kbd.c b/common/usb_kbd.c > > index 020f0d4117f7..74206d2de74f 100644 > > --- a/common/usb_kbd.c > > +++ b/common/usb_kbd.c > > @@ -317,10 +317,9 @@ static inline void usb_kbd_poll_for_event(struct > > usb_device *dev) > > struct usb_kbd_pdata *data = dev->privptr; > > > > /* Submit a interrupt transfer request */ > > - usb_submit_int_msg(dev, data->intpipe, &data->new[0], > > data->intpktsize, > > - data->intinterval); > > - > > - usb_kbd_irq_worker(dev); > > + if (!usb_submit_int_msg(dev, data->intpipe, &data->new[0], > > + data->intpktsize, data->intinterval)) > > The indentation still looks incorrect. It should align to one > character after the open parenthesis. It looks correct after the function is renamed twice in following patches. > > > + usb_kbd_irq_worker(dev); Anyway, the problem I was referring to was excessive indentation of this line in previous version of the patch. Thanks Michal ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/8] usb_kdb: only process events succesfully received
On Tue, 2 Jul 2019 23:20:28 +0200 Marek Vasut wrote: > On 7/2/19 9:31 PM, Michal Suchánek wrote: > > On Tue, 2 Jul 2019 20:38:27 +0200 > > Marek Vasut wrote: > > > >> On 7/2/19 7:50 PM, Michal Suchánek wrote: > >>> On Tue, 2 Jul 2019 18:58:54 +0200 > >>> Marek Vasut wrote: > >>> > >>>> On 7/2/19 4:22 PM, Michal Suchánek wrote: > >>>>> On Tue, 2 Jul 2019 15:11:07 +0200 > >>>>> Marek Vasut wrote: > >>>>> > >>>>>> On 7/2/19 3:04 PM, Michal Suchánek wrote: > >>>>>>> On Tue, 2 Jul 2019 13:58:30 +0200 > >>>>>>> Marek Vasut wrote: > >>>>>>> > >>>>>>>> On 7/1/19 5:56 PM, Michal Suchanek wrote: > >>>>>>>>> Causes unbound key repeat on error otherwise. > >>>>>>>>> > >>>>>>>>> Signed-off-by: Michal Suchanek > >>>>>>>>> --- > >>>>>>>>> common/usb_kbd.c | 7 +++ > >>>>>>>>> 1 file changed, 3 insertions(+), 4 deletions(-) > >>>>>>>>> > >>>>>>>>> diff --git a/common/usb_kbd.c b/common/usb_kbd.c > >>>>>>>>> index cc99c6be0720..948f9fd68490 100644 > >>>>>>>>> --- a/common/usb_kbd.c > >>>>>>>>> +++ b/common/usb_kbd.c > >>>>>>>>> @@ -339,10 +339,9 @@ static inline void > >>>>>>>>> usb_kbd_poll_for_event(struct usb_device *dev) > >>>>>>>>> struct usb_kbd_pdata *data = dev->privptr; > >>>>>>>>> > >>>>>>>>> /* Submit a interrupt transfer request */ > >>>>>>>>> - usb_submit_int_msg(dev, data->intpipe, &data->new[0], > >>>>>>>>> data->intpktsize, > >>>>>>>>> - data->intinterval); > >>>>>>>>> - > >>>>>>>>> - usb_kbd_irq_worker(dev); > >>>>>>>>> + if (!usb_submit_int_msg(dev, data->intpipe, &data->new[0], > >>>>>>>>> > >>>>>>>> > >>>>>>>> Shouldn't you propagate return value from this function ? It can > >>>>>>>> return > >>>>>>>> ENOTSUPP. > >>>>>>>> > >>>>>>> > >>>>>>> If it did then probing keyboard would fail and we would not get here. > >>>>>>> > >>>>>> > >>>>>> So there is no chance this function could return an error here, ever ? > >>>>>> E.g. what if it's implemented and someone yanks the keyboard cable out > >>>>>> just at the right time ? > >>>>> > >>>>> It returns errors all the time with dwc2. That's why we need to check > >>>>> for the error condition. We should not get here if probing the keyboard > >>>>> failed, though. So if the function is not supported we will not get > >>>>> here. Anyway, if it's not supported or the keyboard is missing it by > >>>>> definition cannot provide useful result so we should not process it. > >>>>> > >>>> > >>>> Except you start ignoring the error value from e.g. malfunctioning > >>>> keyboard here, instead of propagating it, correct ? > >>> > >>> It was never propagated to start with. The return value was not checked > >>> at all. What I do here is check the return value and not process the > >>> data on error whatever it contains (like the keypress returned last > >>> time valid data was received). > >> > >> I can see a patch which checks usb_kbd_poll_for_event() return value. > >> Can you add one ? > > > > What for? Apparently the keypress is processed in usb_kbd_irq_worker. > > So checking the return value is needed to decide if the worker should > > run, and is not particularly useful outside usb_kbd_poll_for_event. We > > could signal a getc() failure but do we have any code handling getc() > > failures? > > I presume getc() might signal EOF if the underlying hardware fails. > But in general, it's a good practice to not ignore errors. > It is not such a great idea. You might have multiple input hardware (ie serial and usb keyboard). What does it mean that usb keyboard failed in this context? So in my view the ultimate consumer of getc() has no use for the error so there is no point in propagating it. Thanks Michal ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/8] usb_kdb: only process events succesfully received
On Wed, 3 Jul 2019 13:26:50 +0200 Marek Vasut wrote: > On 7/3/19 11:46 AM, Michal Suchánek wrote: > > On Tue, 2 Jul 2019 23:20:28 +0200 > > Marek Vasut wrote: > > > >> On 7/2/19 9:31 PM, Michal Suchánek wrote: > >>> On Tue, 2 Jul 2019 20:38:27 +0200 > >>> Marek Vasut wrote: > >>> > >>>> On 7/2/19 7:50 PM, Michal Suchánek wrote: > >>>>> On Tue, 2 Jul 2019 18:58:54 +0200 > >>>>> Marek Vasut wrote: > >>>>> > >>>>>> On 7/2/19 4:22 PM, Michal Suchánek wrote: > >>>>>>> On Tue, 2 Jul 2019 15:11:07 +0200 > >>>>>>> Marek Vasut wrote: > >>>>>>> > >>>>>>>> On 7/2/19 3:04 PM, Michal Suchánek wrote: > >>>>>>>>> On Tue, 2 Jul 2019 13:58:30 +0200 > >>>>>>>>> Marek Vasut wrote: > >>>>>>>>> > >>>>>>>>>> On 7/1/19 5:56 PM, Michal Suchanek wrote: > >>>>>>>>>>> Causes unbound key repeat on error otherwise. > >>>>>>>>>>> > >>>>>>>>>>> Signed-off-by: Michal Suchanek > >>>>>>>>>>> --- > >>>>>>>>>>> common/usb_kbd.c | 7 +++ > >>>>>>>>>>> 1 file changed, 3 insertions(+), 4 deletions(-) > >>>>>>>>>>> > >>>>>>>>>>> diff --git a/common/usb_kbd.c b/common/usb_kbd.c > >>>>>>>>>>> index cc99c6be0720..948f9fd68490 100644 > >>>>>>>>>>> --- a/common/usb_kbd.c > >>>>>>>>>>> +++ b/common/usb_kbd.c > >>>>>>>>>>> @@ -339,10 +339,9 @@ static inline void > >>>>>>>>>>> usb_kbd_poll_for_event(struct usb_device *dev) > >>>>>>>>>>> struct usb_kbd_pdata *data = dev->privptr; > >>>>>>>>>>> > >>>>>>>>>>> /* Submit a interrupt transfer request */ > >>>>>>>>>>> - usb_submit_int_msg(dev, data->intpipe, &data->new[0], > >>>>>>>>>>> data->intpktsize, > >>>>>>>>>>> -data->intinterval); > >>>>>>>>>>> - > >>>>>>>>>>> - usb_kbd_irq_worker(dev); > >>>>>>>>>>> + if (!usb_submit_int_msg(dev, data->intpipe, &data->new[0], > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Shouldn't you propagate return value from this function ? It can > >>>>>>>>>> return > >>>>>>>>>> ENOTSUPP. > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> If it did then probing keyboard would fail and we would not get > >>>>>>>>> here. > >>>>>>>> > >>>>>>>> So there is no chance this function could return an error here, ever > >>>>>>>> ? > >>>>>>>> E.g. what if it's implemented and someone yanks the keyboard cable > >>>>>>>> out > >>>>>>>> just at the right time ? > >>>>>>> > >>>>>>> It returns errors all the time with dwc2. That's why we need to check > >>>>>>> for the error condition. We should not get here if probing the > >>>>>>> keyboard > >>>>>>> failed, though. So if the function is not supported we will not get > >>>>>>> here. Anyway, if it's not supported or the keyboard is missing it by > >>>>>>> definition cannot provide useful result so we should not process it. > >>>>>>> > >>>>>> > >>>>>> Except you start ignoring the error value from e.g. malfunctioning > >>>>>> keyboard here, instead of propagating it, correct ? > >>>>> > >>>>> It was never propagated to start with. The return value was not checked > >>>>> at all. What I do here is check the return value and not process the > >>>>> data on error whatever it contains (like the keypress returned last > >>>>> time valid data was received). > >>>> > >>>> I can see a patch which checks usb_kbd_poll_for_event() return value. > >>>> Can you add one ? > >>> > >>> What for? Apparently the keypress is processed in usb_kbd_irq_worker. > >>> So checking the return value is needed to decide if the worker should > >>> run, and is not particularly useful outside usb_kbd_poll_for_event. We > >>> could signal a getc() failure but do we have any code handling getc() > >>> failures? > >> > >> I presume getc() might signal EOF if the underlying hardware fails. > >> But in general, it's a good practice to not ignore errors. > >> > > > > It is not such a great idea. You might have multiple input hardware (ie > > serial and usb keyboard). What does it mean that usb keyboard failed in > > this context? > > I'd say, the behavior is undefined ? But we need to define it which the code does by ignoring the device-specific error and relying on devices that are still working (like a serial port) or for which error detection is not available (like most serial ports). > > > So in my view the ultimate consumer of getc() has no use for the error > > so there is no point in propagating it. > > Ignoring errors and not reporting them isn't nice either, so what other > option(s) do we have here ? Ignoring the errors is exactly the desirable behavior when facing broken hardware like dwc2. On non-broken hardware you will get fewer errors to ignore. It is up to the device driver to report device failure with a message when the error condition could be informative to the user (such as previously working device going away completely). Thanks Michal ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/8] usb_kdb: only process events succesfully received
On Wed, 3 Jul 2019 13:48:00 +0200 Marek Vasut wrote: > On 7/3/19 1:43 PM, Michal Suchánek wrote: > > On Wed, 3 Jul 2019 13:26:50 +0200 > > Marek Vasut wrote: > > > >> On 7/3/19 11:46 AM, Michal Suchánek wrote: > >>> On Tue, 2 Jul 2019 23:20:28 +0200 > >>> Marek Vasut wrote: > >>> > >>>> On 7/2/19 9:31 PM, Michal Suchánek wrote: > >>>>> On Tue, 2 Jul 2019 20:38:27 +0200 > >>>>> Marek Vasut wrote: > >>>>> > >>>>>> On 7/2/19 7:50 PM, Michal Suchánek wrote: > >>>>>>> On Tue, 2 Jul 2019 18:58:54 +0200 > >>>>>>> Marek Vasut wrote: > >>>>>>> > >>>>>>>> On 7/2/19 4:22 PM, Michal Suchánek wrote: > >>>>>>>>> On Tue, 2 Jul 2019 15:11:07 +0200 > >>>>>>>>> Marek Vasut wrote: > >>>>>>>>> > >>>>>>>>>> On 7/2/19 3:04 PM, Michal Suchánek wrote: > >>>>>>>>>>> On Tue, 2 Jul 2019 13:58:30 +0200 > >>>>>>>>>>> Marek Vasut wrote: > >>>>>>>>>>> > >>>>>>>>>>>> On 7/1/19 5:56 PM, Michal Suchanek wrote: > >>>>>>>>>>>>> Causes unbound key repeat on error otherwise. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Signed-off-by: Michal Suchanek > >>>>>>>>>>>>> --- > >>>>>>>>>>>>> common/usb_kbd.c | 7 +++ > >>>>>>>>>>>>> 1 file changed, 3 insertions(+), 4 deletions(-) > >>>>>>>>>>>>> > >>>>>>>>>>>>> diff --git a/common/usb_kbd.c b/common/usb_kbd.c > >>>>>>>>>>>>> index cc99c6be0720..948f9fd68490 100644 > >>>>>>>>>>>>> --- a/common/usb_kbd.c > >>>>>>>>>>>>> +++ b/common/usb_kbd.c > >>>>>>>>>>>>> @@ -339,10 +339,9 @@ static inline void > >>>>>>>>>>>>> usb_kbd_poll_for_event(struct usb_device *dev) > >>>>>>>>>>>>> struct usb_kbd_pdata *data = dev->privptr; > >>>>>>>>>>>>> > >>>>>>>>>>>>> /* Submit a interrupt transfer request */ > >>>>>>>>>>>>> - usb_submit_int_msg(dev, data->intpipe, &data->new[0], > >>>>>>>>>>>>> data->intpktsize, > >>>>>>>>>>>>> - data->intinterval); > >>>>>>>>>>>>> - > >>>>>>>>>>>>> - usb_kbd_irq_worker(dev); > >>>>>>>>>>>>> + if (!usb_submit_int_msg(dev, data->intpipe, > >>>>>>>>>>>>> &data->new[0], > >>>>>>>>>>>> > >>>>>>>>>>>> Shouldn't you propagate return value from this function ? It can > >>>>>>>>>>>> return > >>>>>>>>>>>> ENOTSUPP. > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> If it did then probing keyboard would fail and we would not get > >>>>>>>>>>> here. > >>>>>>>>>> > >>>>>>>>>> So there is no chance this function could return an error here, > >>>>>>>>>> ever ? > >>>>>>>>>> E.g. what if it's implemented and someone yanks the keyboard cable > >>>>>>>>>> out > >>>>>>>>>> just at the right time ? > >>>>>>>>> > >>>>>>>>> It returns errors all the time with dwc2. That's why we need to > >>>>>>>>> check > >>>>>>>>> for the error condition. We should not get here if probing the > >>>
Re: [U-Boot] [PATCH v2 2/9] usb: sl811-hcd: return -ENOTSUPP from unimplemented submit_int_msg
On Tue, 2 Jul 2019 23:20:52 +0200 Marek Vasut wrote: > On 7/2/19 9:35 PM, Michal Suchánek wrote: > > On Tue, 2 Jul 2019 20:41:04 +0200 > > Marek Vasut wrote: > > > >> On 7/2/19 7:55 PM, Michal Suchanek wrote: > >> > >> Commit message is still missing ... > >> > >>> Signed-off-by: Michal Suchanek > >> [...] > > > > It says "usb: sl811-hcd: return -ENOTSUPP from unimplemented > > submit_int_msg" > > That's subject, not commit message. Should I add a dot like in bugzilla when it insists "you must add a comment for this change"? Thanks Michal ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/9] usb: storage: submit_int_msg -> usb_int_msg
On Wed, 3 Jul 2019 09:39:10 +0800 Bin Meng wrote: > On Wed, Jul 3, 2019 at 1:57 AM Michal Suchanek wrote: > > > > Use the wrapper because the unwrapped function prototype will be changed > > in the following patch. > > > > Signed-off-by: Michal Suchanek > > --- > > v2: usb_submit_int_msg -> usb_int_msg > > --- > > common/usb_storage.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/common/usb_storage.c b/common/usb_storage.c > > index 8c889bb1a648..7be965964f09 100644 > > --- a/common/usb_storage.c > > +++ b/common/usb_storage.c > > @@ -650,7 +650,7 @@ static int usb_stor_CBI_get_status(struct scsi_cmd > > *srb, struct us_data *us) > > int timeout; > > > > us->ip_wanted = 1; > > - submit_int_msg(us->pusb_dev, us->irqpipe, > > + usb_int_msg(us->pusb_dev, us->irqpipe, > > (void *) &us->ip_data, us->irqmaxp, > > us->irqinterval); > > Please also change the indentation here. I prefer to not reindent lines I would not need to touch otherwise. Thanks Michal ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/9] usb: sl811-hcd: return -ENOTSUPP from unimplemented submit_int_msg
On Thu, 4 Jul 2019 18:19:20 +0200 Marek Vasut wrote: > On 7/4/19 6:00 PM, Michal Suchánek wrote: > > On Tue, 2 Jul 2019 23:20:52 +0200 > > Marek Vasut wrote: > > > >> On 7/2/19 9:35 PM, Michal Suchánek wrote: > >>> On Tue, 2 Jul 2019 20:41:04 +0200 > >>> Marek Vasut wrote: > >>> > >>>> On 7/2/19 7:55 PM, Michal Suchanek wrote: > >>>> > >>>> Commit message is still missing ... > >>>> > >>>>> Signed-off-by: Michal Suchanek > >>>> [...] > >>> > >>> It says "usb: sl811-hcd: return -ENOTSUPP from unimplemented > >>> submit_int_msg" > >> > >> That's subject, not commit message. > > > > Should I add a dot like in bugzilla when it insists "you must add a > > comment for this change"? > > Please add a commit message which explains the change. > > [...] Which is "usb: sl811-hcd: return -ENOTSUPP from unimplemented submit_int_msg" Thanks Michal ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
