mbox series

[v3,0/9] Add the Renesas USBF controller support

Message ID 20221207162435.1001782-1-herve.codina@bootlin.com
Headers show
Series Add the Renesas USBF controller support | expand

Message

Herve Codina Dec. 7, 2022, 4:24 p.m. UTC
Hi,

This series add support for the Renesas USBF controller (USB Device
Controller) available in the Renesas RZ/N1 SoC.

Based on previous review:
  https://lore.kernel.org/all/20221114111513.1436165-3-herve.codina@bootlin.com/
  
A new strategy is proposed to handle the H2MODE bit from CFG_USB
register compared to the previous versions on the series. As a
reminder, H2MODE bit allows to configure the internal USB Port
interface for two hosts or one host and one device.

This new strategy is:
  - Add the new generic 'depends-on' property in the device tree.

    This generic property expresses an simple functionnal dependency
    that does not rely on a specific topic. It is an 'order only'
    dependency that can be used for dependencies between consumers
    and producers that are not based on a specific infrastructure
    and not need other relationship than this simple 'order only'
    (ie no API is provided between the provider and the consumer)

    The 'depends-on' property is handled in a generic way using
    fw_devlink. The probe() function calls order is ensured by the
    core infrastructure.

    In the nodes impacted by H2MODE, 'depends-on' is used to
    express the dependency to sysctrl.

  - At sysctrl level, during the probe, switch to '1 host, 1 device'
    mode only if the USB device is available.

Patches 1, 2 and 3 are related to 'depends-on' in the PCI bridge
node. This PCI bridge connects the USB host controllers to the AHB bus

Patch 4 adds the 'depends-on' support in fw_devlink
Patch 6 handles h2mode in sysctrl

Patch 5, 7, 8 and 9 are related to the USBF controller with a new
binding definition, the driver itself and myself as a maintainer
of this controller.

Best regards,
Herve Codina

Changes v2 -> v3:
  - v2 Patches 1, 2 and 3 removed.

  - Patches 1, 2, 3 and 4 (new patches)

  - Patch 5 (v2 patch 4):
    Add 'depends-on' property
    Removed redundant 'binding' word

  - Patch 6 (new patch)

  - Patch 7 (v2 patch 5)
    Removed h2mode checking. This check is no more needed and the API no more
    available.

  - Patch 8 (v2 patch 6)
    Add 'depends-on' property

  - Patch 9 (v2 patch 7)
    Fix file name

Changes v1 -> v2:
  - Patch 1:
    Rename r9a06g032_sysctrl_get_usb_h2mode to r9a06g032_sysctrl_get_usb_role
    and return USB_ROLE_{HOST,DEVICE} or an error code.
    Reword commit log

  - Patches 2 and 3:
    No changes. Some previous feedbacks still need to be taken into account
      https://lore.kernel.org/all/20221107182642.05a09f2f@bootlin.com/
      https://lore.kernel.org/all/20221107173614.474707d7@bootlin.com/

  - Patch 4:
    Rename file from renesas,usbf.yaml to renesas,rzn1-usbf.yaml.
    Remove 'oneOf'.
    Add blank line and line break.
    Add 'power-domains'.
    Reword commit log

  - Patch 5:
    Remove clocks handling (handled by runtime PM through the clock domain
    pointed by power-domains).
    Fix compilation warning raised by the 'kernel test robot'.

  - Patch 6:
    Add 'power-domains'

  - Patch 7:
    Add 'Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>'


Herve Codina (9):
  dt-bindings: PCI: renesas,pci-rcar-gen2: Add depends-on for RZ/N1 SoC
    family
  ARM: dts: r9a06g032: Add dependency to sysctrl in the PCI bridge
  dt-bindings: PCI: renesas,pci-rcar-gen2: 'depends-on' is no more
    optional
  of: property: fw_devlink: Add support for "depends-on"
  dt-bindings: usb: add the Renesas RZ/N1 USBF controller
  soc: renesas: r9a06g032-sysctrl: Handle h2mode setting based on USBF
    presence
  usb: gadget: udc: add Renesas RZ/N1 USBF controller support
  ARM: dts: r9a06g032: Add the USBF controller node
  MAINTAINERS: add the Renesas RZ/N1 USBF controller entry

 .../bindings/pci/renesas,pci-rcar-gen2.yaml   |    7 +
 .../bindings/usb/renesas,rzn1-usbf.yaml       |   77 +
 MAINTAINERS                                   |    8 +
 arch/arm/boot/dts/r9a06g032.dtsi              |   14 +
 drivers/clk/renesas/r9a06g032-clocks.c        |   28 +
 drivers/of/property.c                         |    2 +
 drivers/usb/gadget/udc/Kconfig                |   11 +
 drivers/usb/gadget/udc/Makefile               |    1 +
 drivers/usb/gadget/udc/renesas_usbf.c         | 3420 +++++++++++++++++
 9 files changed, 3568 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/renesas,rzn1-usbf.yaml
 create mode 100644 drivers/usb/gadget/udc/renesas_usbf.c

Comments

Rob Herring Dec. 7, 2022, 10:19 p.m. UTC | #1
On Wed, Dec 7, 2022 at 10:24 AM Herve Codina <herve.codina@bootlin.com> wrote:
>
> Hi,
>
> This series add support for the Renesas USBF controller (USB Device
> Controller) available in the Renesas RZ/N1 SoC.
>
> Based on previous review:
>   https://lore.kernel.org/all/20221114111513.1436165-3-herve.codina@bootlin.com/
>
> A new strategy is proposed to handle the H2MODE bit from CFG_USB
> register compared to the previous versions on the series. As a
> reminder, H2MODE bit allows to configure the internal USB Port
> interface for two hosts or one host and one device.

Is this case any different from all the phandle properties we have in
bindings that point to some misc registers somewhere else you need to
poke? If so, I'm not really a fan of duplicating the information.

We also have cases of of_find_compatible_node(NULL, NULL,
"foo-bar-syscon") which is a dependency expressed in the driver, but
not DT. In either case, adding 'depends-on' would be an ABI break as
you are requiring a DT change.

> This new strategy is:
>   - Add the new generic 'depends-on' property in the device tree.
>
>     This generic property expresses an simple functionnal dependency
>     that does not rely on a specific topic. It is an 'order only'
>     dependency that can be used for dependencies between consumers
>     and producers that are not based on a specific infrastructure
>     and not need other relationship than this simple 'order only'
>     (ie no API is provided between the provider and the consumer)

Isn't getting a regmap an API?

Rob
Herve Codina Dec. 8, 2022, 8:24 a.m. UTC | #2
Hi Rob,

On Wed, 7 Dec 2022 16:19:42 -0600
Rob Herring <robh+dt@kernel.org> wrote:

> On Wed, Dec 7, 2022 at 10:24 AM Herve Codina <herve.codina@bootlin.com> wrote:
> >
> > Hi,
> >
> > This series add support for the Renesas USBF controller (USB Device
> > Controller) available in the Renesas RZ/N1 SoC.
> >
> > Based on previous review:
> >   https://lore.kernel.org/all/20221114111513.1436165-3-herve.codina@bootlin.com/
> >
> > A new strategy is proposed to handle the H2MODE bit from CFG_USB
> > register compared to the previous versions on the series. As a
> > reminder, H2MODE bit allows to configure the internal USB Port
> > interface for two hosts or one host and one device.  
> 
> Is this case any different from all the phandle properties we have in
> bindings that point to some misc registers somewhere else you need to
> poke? If so, I'm not really a fan of duplicating the information.

Our case is that there is a bit in a register that affect several
devices. This bit must be set before the devices are started.
If this bit is changed while affected devices are running, system
hangs can occurs (datasheet).

So, in order to do that we need the device in charge to set
this bit (sysctrl) to set this bit before other devices (USBF
and PCI bridge) were started.

At sysctrl level, the bit is set during the probe() call.
The property 'depends-on' aim is to ensure the probe() calls
order between provider (sysctrl) and consumers (USBF and PCI
bridge).

regmap and syscon are used to export registers from one device
to an other and the probe() calls order is not ensured by the
core or regmap infrastructure. Indeed, the regmap provider
probe() will not be called if the regmap provider was not probed
before the consumer ask for the regmap.
  https://elixir.bootlin.com/linux/latest/source/drivers/mfd/syscon.c#L152
  https://elixir.bootlin.com/linux/latest/source/drivers/mfd/syscon.c#L43
No specific action synchronisation are done with regmap/syscon
other than the regmap creation itself.

I don't think the regmap/syscon will help in our case.

> 
> We also have cases of of_find_compatible_node(NULL, NULL,
> "foo-bar-syscon") which is a dependency expressed in the driver, but
> not DT. In either case, adding 'depends-on' would be an ABI break as
> you are requiring a DT change.

In order to avoid the DT change, I can keep the 'depends-on'
optional in the PCI bridge binding.
This will be functionnal as sysctrl is already used in this node
(power-domain = <&sysctrl>). The relationship is already present
with this power-domain link.

If ok, I will do this change in v4 series.

> 
> > This new strategy is:
> >   - Add the new generic 'depends-on' property in the device tree.
> >
> >     This generic property expresses an simple functionnal dependency
> >     that does not rely on a specific topic. It is an 'order only'
> >     dependency that can be used for dependencies between consumers
> >     and producers that are not based on a specific infrastructure
> >     and not need other relationship than this simple 'order only'
> >     (ie no API is provided between the provider and the consumer)  
> 
> Isn't getting a regmap an API?
> 
> Rob
Krzysztof Kozlowski Dec. 8, 2022, 8:26 a.m. UTC | #3
On 07/12/2022 17:24, Herve Codina wrote:
> The 'depends-on' property is set in involved DTS.
> 
> Move it to a required property.
> 
> Signed-off-by: Herve Codina <herve.codina@bootlin.com>
> ---
>  Documentation/devicetree/bindings/pci/renesas,pci-rcar-gen2.yaml | 1 +

This should be squashed with previous patch. There is no point to add
property and immediately in the next patch make it required. Remember
that bindings are separate from DTS.

Best regards,
Krzysztof
Herve Codina Dec. 8, 2022, 9:05 a.m. UTC | #4
Hi Krzysztof,

On Thu, 8 Dec 2022 09:26:41 +0100
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote:

> On 07/12/2022 17:24, Herve Codina wrote:
> > The 'depends-on' property is set in involved DTS.
> > 
> > Move it to a required property.
> > 
> > Signed-off-by: Herve Codina <herve.codina@bootlin.com>
> > ---
> >  Documentation/devicetree/bindings/pci/renesas,pci-rcar-gen2.yaml | 1 +  
> 
> This should be squashed with previous patch. There is no point to add
> property and immediately in the next patch make it required. Remember
> that bindings are separate from DTS.
> 
> Best regards,
> Krzysztof
> 

I though about make dtbs_check in case of git bisect.

But, ok I will squash or perhaps remove completely this commit.
It introduces a DT compatibility break adding a new mandatory
property (raised by Rob on cover letter review).
Is this compatibility break can be acceptable ?

Best regards,
Herve
Geert Uytterhoeven Dec. 8, 2022, 9:09 a.m. UTC | #5
On Wed, Dec 7, 2022 at 5:25 PM Herve Codina <herve.codina@bootlin.com> wrote:
> Add the USBF controller available in the r9a06g032 SoC.
>
> Signed-off-by: Herve Codina <herve.codina@bootlin.com>

My
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
on v2 is still valid.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
Geert Uytterhoeven Dec. 8, 2022, 9:11 a.m. UTC | #6
Hi Hervé,

On Thu, Dec 8, 2022 at 9:24 AM Herve Codina <herve.codina@bootlin.com> wrote:
> On Wed, 7 Dec 2022 16:19:42 -0600
> Rob Herring <robh+dt@kernel.org> wrote:
> > On Wed, Dec 7, 2022 at 10:24 AM Herve Codina <herve.codina@bootlin.com> wrote:
> > > This series add support for the Renesas USBF controller (USB Device
> > > Controller) available in the Renesas RZ/N1 SoC.
> > >
> > > Based on previous review:
> > >   https://lore.kernel.org/all/20221114111513.1436165-3-herve.codina@bootlin.com/
> > >
> > > A new strategy is proposed to handle the H2MODE bit from CFG_USB
> > > register compared to the previous versions on the series. As a
> > > reminder, H2MODE bit allows to configure the internal USB Port
> > > interface for two hosts or one host and one device.
> >
> > Is this case any different from all the phandle properties we have in
> > bindings that point to some misc registers somewhere else you need to
> > poke? If so, I'm not really a fan of duplicating the information.
>
> Our case is that there is a bit in a register that affect several
> devices. This bit must be set before the devices are started.
> If this bit is changed while affected devices are running, system
> hangs can occurs (datasheet).
>
> So, in order to do that we need the device in charge to set
> this bit (sysctrl) to set this bit before other devices (USBF
> and PCI bridge) were started.
>
> At sysctrl level, the bit is set during the probe() call.
> The property 'depends-on' aim is to ensure the probe() calls
> order between provider (sysctrl) and consumers (USBF and PCI
> bridge).

This order is already guaranteed (twice), through the clocks and
power-domains properties in the USB host and device nodes,
all pointing to sysctrl.

So IMHO none of this is needed.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
Krzysztof Kozlowski Dec. 8, 2022, 9:46 a.m. UTC | #7
On 08/12/2022 10:05, Herve Codina wrote:
> Hi Krzysztof,
> 
> On Thu, 8 Dec 2022 09:26:41 +0100
> Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote:
> 
>> On 07/12/2022 17:24, Herve Codina wrote:
>>> The 'depends-on' property is set in involved DTS.
>>>
>>> Move it to a required property.
>>>
>>> Signed-off-by: Herve Codina <herve.codina@bootlin.com>
>>> ---
>>>  Documentation/devicetree/bindings/pci/renesas,pci-rcar-gen2.yaml | 1 +  
>>
>> This should be squashed with previous patch. There is no point to add
>> property and immediately in the next patch make it required. Remember
>> that bindings are separate from DTS.
>>
>> Best regards,
>> Krzysztof
>>
> 
> I though about make dtbs_check in case of git bisect.

And what would this commit change? In Git you will have
1. dt-bindings: PCI: renesas,pci-rcar-gen2: Add depends-on for RZ/N1 SoC
family
2. dt-bindings: PCI: renesas,pci-rcar-gen2: 'depends-on' is no more optional

so what is the difference for git bisect?

> 
> But, ok I will squash or perhaps remove completely this commit.
> It introduces a DT compatibility break adding a new mandatory
> property (raised by Rob on cover letter review).
> Is this compatibility break can be acceptable ?

Requiring property in bindings as a fix for something which was broken
is ok. But this is independent of Linux drivers, which should not stop
working.

Best regards,
Krzysztof
Herve Codina Dec. 8, 2022, 3:51 p.m. UTC | #8
Hi Krzysztof,

On Thu, 8 Dec 2022 10:46:32 +0100
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote:

> On 08/12/2022 10:05, Herve Codina wrote:
> > Hi Krzysztof,
> > 
> > On Thu, 8 Dec 2022 09:26:41 +0100
> > Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote:
> >   
> >> On 07/12/2022 17:24, Herve Codina wrote:  
> >>> The 'depends-on' property is set in involved DTS.
> >>>
> >>> Move it to a required property.
> >>>
> >>> Signed-off-by: Herve Codina <herve.codina@bootlin.com>
> >>> ---
> >>>  Documentation/devicetree/bindings/pci/renesas,pci-rcar-gen2.yaml | 1 +    
> >>
> >> This should be squashed with previous patch. There is no point to add
> >> property and immediately in the next patch make it required. Remember
> >> that bindings are separate from DTS.
> >>
> >> Best regards,
> >> Krzysztof
> >>  
> > 
> > I though about make dtbs_check in case of git bisect.  
> 
> And what would this commit change? In Git you will have
> 1. dt-bindings: PCI: renesas,pci-rcar-gen2: Add depends-on for RZ/N1 SoC
> family
> 2. dt-bindings: PCI: renesas,pci-rcar-gen2: 'depends-on' is no more optional
> 
> so what is the difference for git bisect?

Well, today, I have:
1. dt-bindings: Add depends-on
2. dts: Add depends-on
3. dt-bindings: Move depends-on to mandatory

If I squash dt-bindings commits, I am going to have:
  1. dt-bindings: Add mandatory depends-on
  2. dts: Add depends-on
or
  1. dts: Add depends-on
  2. dt-bindings: Add mandatory depends-on

I have not tested but if I used only the first commit in each
case (git bisect):
In the first case, dtbs_check is probably going to signal the
missing 'depends-on' property on dts.
In the second case, dtbs_check is probably going to signal the
not described 'depends-on' property present in dts.

> 
> > 
> > But, ok I will squash or perhaps remove completely this commit.
> > It introduces a DT compatibility break adding a new mandatory
> > property (raised by Rob on cover letter review).
> > Is this compatibility break can be acceptable ?  
> 
> Requiring property in bindings as a fix for something which was broken
> is ok. But this is independent of Linux drivers, which should not stop
> working.

Ok, thanks.

> 
> Best regards,
> Krzysztof
> 

Regards,
Hervé
Rob Herring Dec. 8, 2022, 8:44 p.m. UTC | #9
On Thu, Dec 8, 2022 at 2:24 AM Herve Codina <herve.codina@bootlin.com> wrote:
>
> Hi Rob,
>
> On Wed, 7 Dec 2022 16:19:42 -0600
> Rob Herring <robh+dt@kernel.org> wrote:
>
> > On Wed, Dec 7, 2022 at 10:24 AM Herve Codina <herve.codina@bootlin.com> wrote:
> > >
> > > Hi,
> > >
> > > This series add support for the Renesas USBF controller (USB Device
> > > Controller) available in the Renesas RZ/N1 SoC.
> > >
> > > Based on previous review:
> > >   https://lore.kernel.org/all/20221114111513.1436165-3-herve.codina@bootlin.com/
> > >
> > > A new strategy is proposed to handle the H2MODE bit from CFG_USB
> > > register compared to the previous versions on the series. As a
> > > reminder, H2MODE bit allows to configure the internal USB Port
> > > interface for two hosts or one host and one device.
> >
> > Is this case any different from all the phandle properties we have in
> > bindings that point to some misc registers somewhere else you need to
> > poke? If so, I'm not really a fan of duplicating the information.
>
> Our case is that there is a bit in a register that affect several
> devices. This bit must be set before the devices are started.
> If this bit is changed while affected devices are running, system
> hangs can occurs (datasheet).
>
> So, in order to do that we need the device in charge to set
> this bit (sysctrl) to set this bit before other devices (USBF
> and PCI bridge) were started.

That sounds like you just need some platform level initialization and
you are working around the desire to not have platform level
initialization.

Why doesn't/can't the bootloader initialize this? Seems like it might
want to use PCI or USB too.

> At sysctrl level, the bit is set during the probe() call.
> The property 'depends-on' aim is to ensure the probe() calls
> order between provider (sysctrl) and consumers (USBF and PCI
> bridge).
>
> regmap and syscon are used to export registers from one device
> to an other and the probe() calls order is not ensured by the
> core or regmap infrastructure. Indeed, the regmap provider
> probe() will not be called if the regmap provider was not probed
> before the consumer ask for the regmap.
>   https://elixir.bootlin.com/linux/latest/source/drivers/mfd/syscon.c#L152
>   https://elixir.bootlin.com/linux/latest/source/drivers/mfd/syscon.c#L43
> No specific action synchronisation are done with regmap/syscon
> other than the regmap creation itself.

Oh right. That's in place of course to avoid probe ordering issues...

> I don't think the regmap/syscon will help in our case.
>
> >
> > We also have cases of of_find_compatible_node(NULL, NULL,
> > "foo-bar-syscon") which is a dependency expressed in the driver, but
> > not DT. In either case, adding 'depends-on' would be an ABI break as
> > you are requiring a DT change.
>
> In order to avoid the DT change, I can keep the 'depends-on'
> optional in the PCI bridge binding.
> This will be functionnal as sysctrl is already used in this node
> (power-domain = <&sysctrl>). The relationship is already present
> with this power-domain link.
>
> If ok, I will do this change in v4 series.

I agree with Geert that this shouldn't be needed.

Rob
Herve Codina Dec. 13, 2022, 1:22 p.m. UTC | #10
Hi Krzysztof,

On Fri, 9 Dec 2022 09:06:55 +0100
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote:

> On 08/12/2022 16:51, Herve Codina wrote:
> > Hi Krzysztof,
> > 
> > On Thu, 8 Dec 2022 10:46:32 +0100
> > Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote:
> >   
> >> On 08/12/2022 10:05, Herve Codina wrote:  
> >>> Hi Krzysztof,
> >>>
> >>> On Thu, 8 Dec 2022 09:26:41 +0100
> >>> Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote:
> >>>     
> >>>> On 07/12/2022 17:24, Herve Codina wrote:    
> >>>>> The 'depends-on' property is set in involved DTS.
> >>>>>
> >>>>> Move it to a required property.
> >>>>>
> >>>>> Signed-off-by: Herve Codina <herve.codina@bootlin.com>
> >>>>> ---
> >>>>>  Documentation/devicetree/bindings/pci/renesas,pci-rcar-gen2.yaml | 1 +      
> >>>>
> >>>> This should be squashed with previous patch. There is no point to add
> >>>> property and immediately in the next patch make it required. Remember
> >>>> that bindings are separate from DTS.
> >>>>
> >>>> Best regards,
> >>>> Krzysztof
> >>>>    
> >>>
> >>> I though about make dtbs_check in case of git bisect.    
> >>
> >> And what would this commit change? In Git you will have
> >> 1. dt-bindings: PCI: renesas,pci-rcar-gen2: Add depends-on for RZ/N1 SoC
> >> family
> >> 2. dt-bindings: PCI: renesas,pci-rcar-gen2: 'depends-on' is no more optional
> >>
> >> so what is the difference for git bisect?  
> > 
> > Well, today, I have:
> > 1. dt-bindings: Add depends-on
> > 2. dts: Add depends-on
> > 3. dt-bindings: Move depends-on to mandatory  
> 
> What does it mean "I have"? Patches on mailing list? But we talk about
> Git and I wrote you bindings are DTS are not going the same tree.
> 
> > 
> > If I squash dt-bindings commits, I am going to have:
> >   1. dt-bindings: Add mandatory depends-on
> >   2. dts: Add depends-on
> > or
> >   1. dts: Add depends-on
> >   2. dt-bindings: Add mandatory depends-on  
> 
> And how does it matter? Anyway it goes separate trees.

I finally understand what you mean by separate trees.
And indeed, you're right, my patches split does not make
any sense.

According to feedbacks on this v3 series, these 3 patches
will be removed in v4.

Thanks for the review,
Hervé
Herve Codina Dec. 13, 2022, 1:26 p.m. UTC | #11
Hi Rob, Geert,

On Thu, 8 Dec 2022 14:44:31 -0600
Rob Herring <robh+dt@kernel.org> wrote:

[...]
> 
> Oh right. That's in place of course to avoid probe ordering issues...
> 
[...]
> 
> I agree with Geert that this shouldn't be needed.
> 

In the v4 series, I am going to fully remove the 'depends-on'
property.

Thanks for the review.
Hervé
Herve Codina Dec. 13, 2022, 1:27 p.m. UTC | #12
Hi Geert,

On Thu, 8 Dec 2022 10:09:01 +0100
Geert Uytterhoeven <geert@linux-m68k.org> wrote:

> On Wed, Dec 7, 2022 at 5:25 PM Herve Codina <herve.codina@bootlin.com> wrote:
> > Add the USBF controller available in the r9a06g032 SoC.
> >
> > Signed-off-by: Herve Codina <herve.codina@bootlin.com>  
> 
> My
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> on v2 is still valid.
> 

Will be added in v4.

Thanks for the review,
Hervé