Document RZ/G1H (R8A7742) SoC bindings.
Signed-off-by: Lad Prabhakar <[email protected]>
Reviewed-by: Marian-Cristian Rotariu <[email protected]>
---
Documentation/devicetree/bindings/spi/renesas,sh-msiof.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/spi/renesas,sh-msiof.yaml b/Documentation/devicetree/bindings/spi/renesas,sh-msiof.yaml
index b6c1dd2..910be66 100644
--- a/Documentation/devicetree/bindings/spi/renesas,sh-msiof.yaml
+++ b/Documentation/devicetree/bindings/spi/renesas,sh-msiof.yaml
@@ -21,6 +21,7 @@ properties:
# device
- items:
- enum:
+ - renesas,msiof-r8a7742 # RZ/G1H
- renesas,msiof-r8a7743 # RZ/G1M
- renesas,msiof-r8a7744 # RZ/G1N
- renesas,msiof-r8a7745 # RZ/G1E
--
2.7.4
On Tue, Jun 9, 2020 at 10:54 PM Lad Prabhakar
<[email protected]> wrote:
> Document RZ/G1H (R8A7742) SoC bindings.
>
> Signed-off-by: Lad Prabhakar <[email protected]>
> Reviewed-by: Marian-Cristian Rotariu <[email protected]>
Reviewed-by: Geert Uytterhoeven <[email protected]>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
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
On Tue, Jun 09, 2020 at 09:54:13PM +0100, Lad Prabhakar wrote:
> Document RZ/G1H (R8A7742) SoC bindings.
>
> Signed-off-by: Lad Prabhakar <[email protected]>
> Reviewed-by: Marian-Cristian Rotariu <[email protected]>
> ---
> Documentation/devicetree/bindings/spi/renesas,sh-msiof.yaml | 1 +
> 1 file changed, 1 insertion(+)
To repeat my previous feedback I'd expect a driver update as well.
Hi Mark,
On Wed, Jun 10, 2020 at 1:08 PM Mark Brown <[email protected]> wrote:
> On Tue, Jun 09, 2020 at 09:54:13PM +0100, Lad Prabhakar wrote:
> > Document RZ/G1H (R8A7742) SoC bindings.
> >
> > Signed-off-by: Lad Prabhakar <[email protected]>
> > Reviewed-by: Marian-Cristian Rotariu <[email protected]>
> > ---
> > Documentation/devicetree/bindings/spi/renesas,sh-msiof.yaml | 1 +
> > 1 file changed, 1 insertion(+)
>
> To repeat my previous feedback I'd expect a driver update as well.
No driver update is needed.
Documentation/devicetree/bindings/spi/renesas,sh-msiof.yaml says:
compatible:
oneOf:
- items:
- enum:
- renesas,msiof-r8a7742 # RZ/G1H
...
- const: renesas,rcar-gen2-msiof # generic R-Car Gen2 and RZ/G1
# compatible device
drivers/spi/spi-sh-msiof.c matches against "renesas,rcar-gen2-msiof".
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
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
On Wed, Jun 10, 2020 at 01:59:24PM +0200, Geert Uytterhoeven wrote:
> On Wed, Jun 10, 2020 at 1:08 PM Mark Brown <[email protected]> wrote:
> > To repeat my previous feedback I'd expect a driver update as well.
> No driver update is needed.
> Documentation/devicetree/bindings/spi/renesas,sh-msiof.yaml says:
I'm much more comfortable explicitly listing the new compatible so that
even if someone makes a DT that doesn't bother listing the fallbacks
things will work.
Hi Mark,
On Wed, Jun 10, 2020 at 6:49 PM Mark Brown <[email protected]> wrote:
> On Wed, Jun 10, 2020 at 01:59:24PM +0200, Geert Uytterhoeven wrote:
> > On Wed, Jun 10, 2020 at 1:08 PM Mark Brown <[email protected]> wrote:
> > > To repeat my previous feedback I'd expect a driver update as well.
>
> > No driver update is needed.
>
> > Documentation/devicetree/bindings/spi/renesas,sh-msiof.yaml says:
>
> I'm much more comfortable explicitly listing the new compatible so that
> even if someone makes a DT that doesn't bother listing the fallbacks
> things will work.
Adding all of them would cause even more churn when adding support for
a new SoC... There are already more than 700 "renesas," compatible
values documented that are not directly matched by drivers.
Nowadays we have "make dtbs_check", so if a DTS doesn't conform to the
binding, it will be flagged.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
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
On Wed, Jun 10, 2020 at 09:18:19PM +0200, Geert Uytterhoeven wrote:
> On Wed, Jun 10, 2020 at 6:49 PM Mark Brown <[email protected]> wrote:
> > I'm much more comfortable explicitly listing the new compatible so that
> > even if someone makes a DT that doesn't bother listing the fallbacks
> > things will work.
> Adding all of them would cause even more churn when adding support for
> a new SoC... There are already more than 700 "renesas," compatible
> values documented that are not directly matched by drivers.
I'm not sure it's a particular concern, especially since you'll be
sending this stuff in the same series as a bindings update and an extra
patch in a series makes very little difference.
> Nowadays we have "make dtbs_check", so if a DTS doesn't conform to the
> binding, it will be flagged.
For things that are upstream.
Hi Mark,
On Thu, Jun 11, 2020 at 10:50 AM Mark Brown <[email protected]> wrote:
> On Wed, Jun 10, 2020 at 09:18:19PM +0200, Geert Uytterhoeven wrote:
> > On Wed, Jun 10, 2020 at 6:49 PM Mark Brown <[email protected]> wrote:
>
> > > I'm much more comfortable explicitly listing the new compatible so that
> > > even if someone makes a DT that doesn't bother listing the fallbacks
> > > things will work.
>
> > Adding all of them would cause even more churn when adding support for
> > a new SoC... There are already more than 700 "renesas," compatible
> > values documented that are not directly matched by drivers.
>
> I'm not sure it's a particular concern, especially since you'll be
> sending this stuff in the same series as a bindings update and an extra
> patch in a series makes very little difference.
Until the DT bindings are split off into their own project...
Listing unneeded compatible values in drivers also increases binary size.
For RSPI and MSIOF that would be +2.5 KiB each. Times tens of drivers.
Considering the RSPI driver itself is only 9 KiB, and some RZ/A1 systems
are really memory-constrained, I think it's better to avoid that.
> > Nowadays we have "make dtbs_check", so if a DTS doesn't conform to the
> > binding, it will be flagged.
>
> For things that are upstream.
The DT bindings apply to out-of-tree DTS files, too ;-)
If they're not compliant, all odds are off.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
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
On Thu, Jun 11, 2020 at 02:09:54PM +0200, Geert Uytterhoeven wrote:
> On Thu, Jun 11, 2020 at 10:50 AM Mark Brown <[email protected]> wrote:
> > I'm not sure it's a particular concern, especially since you'll be
> > sending this stuff in the same series as a bindings update and an extra
> > patch in a series makes very little difference.
> Until the DT bindings are split off into their own project...
> Listing unneeded compatible values in drivers also increases binary size.
> For RSPI and MSIOF that would be +2.5 KiB each. Times tens of drivers.
> Considering the RSPI driver itself is only 9 KiB, and some RZ/A1 systems
> are really memory-constrained, I think it's better to avoid that.
That is an issue, though I can't help wondering if space constrained
systems could use some sort of automatic compaction of the ID tables
during install. We're also bloating their DTs by adding fallbacks of
course!
> > > Nowadays we have "make dtbs_check", so if a DTS doesn't conform to the
> > > binding, it will be flagged.
> > For things that are upstream.
> The DT bindings apply to out-of-tree DTS files, too ;-)
> If they're not compliant, all odds are off.
The point here is to improve robustness and make the interface less
fragile.