From: Geert Uytterhoeven <geert@linux-m68k.org> To: Simon Horman <horms@verge.net.au> Cc: Geert Uytterhoeven <geert+renesas@glider.be>, Magnus Damm <magnus.damm@gmail.com>, Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>, Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>, Laurent Pinchart <laurent.pinchart@ideasonboard.com>, Wolfram Sang <wsa+renesas@sang-engineering.com>, Sjoerd Simons <sjoerd.simons@collabora.co.uk>, Linux-Renesas <linux-renesas-soc@vger.kernel.org>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org> Subject: Re: [PATCH v3 1/3] arm64: dts: r8a7795: Add support for R-Car H3 ES2.0 Date: Thu, 11 May 2017 17:42:27 +0200 [thread overview] Message-ID: <CAMuHMdU0NUFtqDOKnRHQuSXurP6NKy7bNVhBQB-_MOoSrnNpYQ@mail.gmail.com> (raw) In-Reply-To: <20170511145329.GD21895@verge.net.au> Hi Simon, On Thu, May 11, 2017 at 4:53 PM, Simon Horman <horms@verge.net.au> wrote: > On Thu, May 11, 2017 at 01:58:52PM +0200, Geert Uytterhoeven wrote: >> Update r8a7795.dtsi so it corresponds to R-Car H3 ES2.0 or later: >> - The following devices no longer exist on ES2.0, and are thus removed: >> fcpf2, fcpvd3, fcpvi2, fdp1-2, usb3-if1, vspd3, vspi2. >> - The DU <-> VSPD topology is different on ES2.0, hence remove the >> "compatible" and "vsps" properties from the DU node until the driver >> can handle this. >> >> Move support for the ES1.x revision of the R-Car H3 SoC into a >> separate file. To avoid duplication, r8a7795-es1.dtsi includes >> r8a7795.dtsi, add adds/removes/overrides device nodes and properties >> where needed. > > I think the above should be re-worded given your explanation below the > scissors that no deletion or overriding occurs. I wanted to document clearly what needs to be done in the generic case... I agree no removal or override is done right now. If you prefer it that way, I can reword it. >> Switch r8a7795-salvator-x.dts and r8a7795-h3ulcb.dts from r8a7795.dtsi >> to r8a7795-es1.dtsi to preserve compatibility. >> >> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> >> --- >> While currently r8a7795-es1.dtsi only adds device nodes, removal of >> devices nodes and properties can be implemented using the /delete-node/ >> and /delete-property/ keywords, as shown below: >> >> &soc { >> /delete-node/ <name>@<addr>; >> }; >> >> &<label> { >> /delete-property/ <prop>; >> }; > > I would be interested to also see an example of an override and > for the examples to be included in the changelog itself. You mean above the scissors? ;-) Currently we don't have any devices or properties in DT that need removals or overrides. Note that I did test those. If we add the "vsps" property to the DU node for ES2.0, we can have an override for it now. But we've plenty of experience with letting .dts override properties in .dtsi. For node deletion, we'll have to wait until someone enables the extra USB channels on ES2.0. For property deletion, I don't have an actual example in mind, but I wanted to be sure that worked in case we ever need it. 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
WARNING: multiple messages have this Message-ID (diff)
From: geert@linux-m68k.org (Geert Uytterhoeven) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH v3 1/3] arm64: dts: r8a7795: Add support for R-Car H3 ES2.0 Date: Thu, 11 May 2017 17:42:27 +0200 [thread overview] Message-ID: <CAMuHMdU0NUFtqDOKnRHQuSXurP6NKy7bNVhBQB-_MOoSrnNpYQ@mail.gmail.com> (raw) In-Reply-To: <20170511145329.GD21895@verge.net.au> Hi Simon, On Thu, May 11, 2017 at 4:53 PM, Simon Horman <horms@verge.net.au> wrote: > On Thu, May 11, 2017 at 01:58:52PM +0200, Geert Uytterhoeven wrote: >> Update r8a7795.dtsi so it corresponds to R-Car H3 ES2.0 or later: >> - The following devices no longer exist on ES2.0, and are thus removed: >> fcpf2, fcpvd3, fcpvi2, fdp1-2, usb3-if1, vspd3, vspi2. >> - The DU <-> VSPD topology is different on ES2.0, hence remove the >> "compatible" and "vsps" properties from the DU node until the driver >> can handle this. >> >> Move support for the ES1.x revision of the R-Car H3 SoC into a >> separate file. To avoid duplication, r8a7795-es1.dtsi includes >> r8a7795.dtsi, add adds/removes/overrides device nodes and properties >> where needed. > > I think the above should be re-worded given your explanation below the > scissors that no deletion or overriding occurs. I wanted to document clearly what needs to be done in the generic case... I agree no removal or override is done right now. If you prefer it that way, I can reword it. >> Switch r8a7795-salvator-x.dts and r8a7795-h3ulcb.dts from r8a7795.dtsi >> to r8a7795-es1.dtsi to preserve compatibility. >> >> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> >> --- >> While currently r8a7795-es1.dtsi only adds device nodes, removal of >> devices nodes and properties can be implemented using the /delete-node/ >> and /delete-property/ keywords, as shown below: >> >> &soc { >> /delete-node/ <name>@<addr>; >> }; >> >> &<label> { >> /delete-property/ <prop>; >> }; > > I would be interested to also see an example of an override and > for the examples to be included in the changelog itself. You mean above the scissors? ;-) Currently we don't have any devices or properties in DT that need removals or overrides. Note that I did test those. If we add the "vsps" property to the DU node for ES2.0, we can have an override for it now. But we've plenty of experience with letting .dts override properties in .dtsi. For node deletion, we'll have to wait until someone enables the extra USB channels on ES2.0. For property deletion, I don't have an actual example in mind, but I wanted to be sure that worked in case we ever need it. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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
next prev parent reply other threads:[~2017-05-11 15:42 UTC|newest] Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-05-11 11:58 [PATCH v3 0/3] arm64: dts: r8a7795: Add support for R-Car H3 ES2.0 Geert Uytterhoeven 2017-05-11 11:58 ` Geert Uytterhoeven 2017-05-11 11:58 ` [PATCH v3 1/3] " Geert Uytterhoeven 2017-05-11 11:58 ` Geert Uytterhoeven 2017-05-11 14:53 ` Simon Horman 2017-05-11 14:53 ` Simon Horman 2017-05-11 15:42 ` Geert Uytterhoeven [this message] 2017-05-11 15:42 ` Geert Uytterhoeven 2017-05-12 7:32 ` Simon Horman 2017-05-12 7:32 ` Simon Horman 2017-05-12 9:49 ` Geert Uytterhoeven 2017-05-12 9:49 ` Geert Uytterhoeven 2017-05-15 5:37 ` Simon Horman 2017-05-15 5:37 ` Simon Horman 2017-05-11 11:58 ` [PATCH v3 2/3] arm64: dts: r8a7795: salvator-x: " Geert Uytterhoeven 2017-05-11 11:58 ` Geert Uytterhoeven 2017-05-11 14:53 ` Simon Horman 2017-05-11 14:53 ` Simon Horman 2017-05-11 15:18 ` Geert Uytterhoeven 2017-05-11 15:18 ` Geert Uytterhoeven 2017-05-12 7:29 ` Simon Horman 2017-05-12 7:29 ` Simon Horman 2017-05-11 11:58 ` [PATCH v3 3/3] arm64: dts: r8a7795: h3ulcb: " Geert Uytterhoeven 2017-05-11 11:58 ` Geert Uytterhoeven
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CAMuHMdU0NUFtqDOKnRHQuSXurP6NKy7bNVhBQB-_MOoSrnNpYQ@mail.gmail.com \ --to=geert@linux-m68k.org \ --cc=geert+renesas@glider.be \ --cc=horms@verge.net.au \ --cc=kuninori.morimoto.gx@renesas.com \ --cc=laurent.pinchart@ideasonboard.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-renesas-soc@vger.kernel.org \ --cc=magnus.damm@gmail.com \ --cc=sjoerd.simons@collabora.co.uk \ --cc=wsa+renesas@sang-engineering.com \ --cc=yoshihiro.shimoda.uh@renesas.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.