From: Biju Das <biju.das.jz@bp.renesas.com> Date: 2021-08-12 15:18:16
This patch series aims to add USB2.0 Host and device support for RZ/G2L SoC.
This patch series is based on renesas-devel.
v5->v6:
* Updated phyrst node with status disabled
* Added Geert's Rb tag for SoC dtsi patches
* Sorted defconfig patch alphabetically.
* Removed USB2.0 phy driver/binding patches as it is accepted for phy/next
* Removed USBHS binding patches as it is accepted for usb/next.
v4->v5:
* Removed USBPHY control and binding patches as it is accepted for reset/next
* Removed USB ehci/ohci binding patches as it is accepted for usb/next.
* Updated Renesas USB2.0 PHY bindings to just use 'resets' as required.
* Added interrupts maxitems=1 for SoC other than RZ/G2L for Renesas USBHS bindings
* Updated the commit description for USB2.0 PHY driver patch.
v3->v4:
* Added Rob's Acked-by tag for generic-{ohci,ehci} binding patch
* Added Rob's Rb tag for RZ/G2L USBPHY control binding patch
* Incorporated Phillip's review comments for USBPHY control driver.
* Dropped second reset from usb2-phy binding patch
* Added maxitems as per Rob's review comment.
v2->v3
* USBPHY Control IP modelled as reset bindings as per Rob's suggestion
* Updated the binding patches
* Incorporated Geert's and Shimoda-San's review comment for phy driver patch.
v1->v2
* Updated usb phy control bindings with clock definitions
* Updated generic ohci/ehci bindings to support RZ/G2L SoC
* Incorporated vinod's review comment on usb phy control driver
* Add support for USB2.0 device and OTG support.
Biju Das (3):
arm64: defconfig: Enable RZ/G2L USBPHY control driver
arm64: dts: renesas: r9a07g044: Add USB2.0 phy and host support
arm64: dts: renesas: r9a07g044: Add USB2.0 device support
arch/arm64/boot/dts/renesas/r9a07g044.dtsi | 114 +++++++++++++++++++++
arch/arm64/configs/defconfig | 1 +
2 files changed, 115 insertions(+)
--
2.17.1
Don't we need to specify "interrupt-names" when there a more than 1
interrupts?
This dtsi changes, as per binding documentation [1]. As you see,
"interrupt-names" is optional.
For now I will go with current dt changes.
Later I will create incremental patches for dt-binding with optional "interrupt-names",
"clock-names" and "reset names" for all the SoC's supported by this binding doc.
After that, will send an incremental patch with adding optional properties in all SoC dtsi.
Does it make sense?
Regards,
Biju
Don't we need to specify "interrupt-names" when there a more than 1
interrupts?
This dtsi changes, as per binding documentation [1]. As you see,
"interrupt-names" is optional.
For now I will go with current dt changes.
Later I will create incremental patches for dt-binding with optional "interrupt-names",
"clock-names" and "reset names" for all the SoC's supported by this binding doc.
After that, will send an incremental patch with adding optional properties in all SoC dtsi.
Does it make sense?
I had the impression that the "*-names" prop was mandatory for a "*" prop having 2 values or mores.
If it's now allowed to be optional, don't bother with that at all.
Don't we need to specify "interrupt-names" when there a more than 1
interrupts?
This dtsi changes, as per binding documentation [1]. As you see,
"interrupt-names" is optional.
For now I will go with current dt changes.
Later I will create incremental patches for dt-binding with optional "interrupt-names",
"clock-names" and "reset names" for all the SoC's supported by this binding doc.
After that, will send an incremental patch with adding optional properties in all SoC dtsi.
Does it make sense?
I had the impression that the "*-names" prop was mandatory for a "*" prop having 2 values or mores.
If it's now allowed to be optional, don't bother with that at all.
There's a difference between "mandatory according to good DT
binding design" and "mandatory according to the actual json-schema
DT bindings". For now the tools only enforce the latter...
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