From: "Andreas Färber" <afaerber@suse.de> To: Rob Herring <robh@kernel.org> Cc: "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>, "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>, "Geert Uytterhoeven" <geert+renesas@glider.be>, linux-realtek-soc@lists.infradead.org, "Tony Lindgren" <tony@atomide.com>, "Linus Walleij" <linus.walleij@linaro.org>, "Bjorn Andersson" <bjorn.andersson@linaro.org>, "Thierry Reding" <thierry.reding@gmail.com>, "Fabio Estevam" <festevam@gmail.com>, "Kevin Hilman" <khilman@baylibre.com>, "Rafael J. Wysocki" <rafael@kernel.org>, "Michal Simek" <michal.simek@xilinx.com>, "Jonathan Hunter" <jonathanh@nvidia.com>, "NXP Linux Team" <linux-imx@nxp.com>, "Sascha Hauer" <s.hauer@pengutronix.de>, "linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>, linux-amlogic@lists.infradead.org, "Lee Jones" <lee.jones@linaro.org>, linux-omap <linux-omap@vger.kernel.org>, "Alexander Sverdlin" <alexander.sverdlin@gmail.com>, LAKML <linux-arm-kernel@lists.infradead.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "Hartley Sweeten" <hsweeten@visionengravers.com>, "Pengutronix Kernel Team" <kernel@pengutronix.de>, "Shawn Guo" <shawnguo@kernel.org>, "Architecture Mailman List" <boot-architecture@lists.linaro.org>, DTML <devicetree@vger.kernel.org> Subject: Re: Sense of soc bus? (was: [PATCH] base: soc: Export soc_device_to_device() helper) Date: Fri, 15 Nov 2019 12:49:22 +0100 Message-ID: <8411cceb-56f1-bcb3-96b6-5a2aaedd18cf@suse.de> (raw) In-Reply-To: <CAL_JsqLr=fw6zxa=69rtgZ4oxzdw=cVDr3km5ya0pRGsNT1xLw@mail.gmail.com> Am 14.11.19 um 23:09 schrieb Rob Herring: > On Tue, Nov 12, 2019 at 4:47 AM Andreas Färber <afaerber@suse.de> wrote: >> Finally, arch/arm seems unique in that it has the machine_desc mechanism >> that allows individual SoCs to force creating their soc_device early and >> using it as parent for further DT-created platform_devices. With arm64 >> we've lost that ability, and nios2 is not using it either. >> A bad side effect (with SUSE hat on) is that this parent design pattern >> does not allow to build such drivers as modules, which means that distro >> configs using arm's multi-platform, e.g., CONFIG_ARCH_MULTI_V7 will get >> unnecessary code creep as new platforms get added over time (beyond the >> basic clk, pinctrl, tty and maybe timer). >> Even if it were possible to call into a driver module that early, using >> it as parent would seem to imply that all the references by its children >> would not allow to unload the module, which I'd consider a flawed design >> for such an "optional" read-once driver. If we want the device hierarchy >> to have a soc root then most DT based platforms will have a /soc DT node >> anyway (although no device_type = "soc") that we probably could have a >> device registered for in common code rather than each SoC platform >> handling that differently? That might then make soc_register_device() >> not the creator of the device (if pre-existent) but the supplier of data >> to that core device, which should then allow to unload the data provider >> with just the sysfs data disappearing until re-inserted (speeding up the >> develop-and-test cycle on say not-so-resource-constrained platforms). > > I for one would like to for this to be consistent. Either we always > have an SoC device parent or never. I wouldn't decide based on having > a DT node or not either. Sure, if we can always be consistent, that might be best. Where I was coming from here is that, if we're not supposed to use soc_device_to_device(), then we have no way to associate an of_node with the soc_device from the outside (and nobody was doing it today, as per my analysis). We'd either need a new helper of_soc_device_register() with additional argument for the node, or it would need to be done entirely in the infrastructure as I suggested, be it by looking for one hardcoded /soc node or for nodes with device_type = "soc". Rob, in light of this discussion, should we start adding the latter property for new DTs such as my new Realtek SoCs, or was there a reason this has not been used consistently outside of powerpc and nios2? Intel/Altera appear to be the only two in arm64, with only three more in arm, none in mips. (BTW my assumption was that we don't follow the booting-without-of.txt documented schema of soc<SOCname> so that we can share .dtsi across differently named SoCs, is that correct?) > Generally, we should always have MMIO devices > under a bus node and perhaps more than one, but that doesn't always > happen. I think building the drivers as modules is a good reason to do > away with the parent device. > > It would also allow getting rid of remaining > of_platform_default_populate calls in arm platforms except for auxdata > cases. Pretty much that's the ones you list below in arch/arm/. The majority was indeed passing in NULL, so yeah, we might clean that up, if someone could come up with a plan of where/how to implement it. Cheers, Andreas -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg)
next prev parent reply index Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-11-03 1:36 [RFC 00/11] ARM: Realtek RTD1195/RTD1295 SoC info Andreas Färber 2019-11-03 1:36 ` [RFC 01/11] dt-bindings: soc: Add Realtek RTD1195 chip info binding Andreas Färber 2019-11-06 4:41 ` Rob Herring 2019-11-03 1:36 ` [RFC 02/11] soc: Add Realtek chip info driver for RTD1195 and RTD1295 Andreas Färber 2019-11-03 1:45 ` Andreas Färber 2019-11-11 4:56 ` [PATCH] base: soc: Export soc_device_to_device() helper Andreas Färber 2019-11-11 5:27 ` Greg Kroah-Hartman 2019-11-11 5:42 ` Andreas Färber 2019-11-11 6:40 ` Greg Kroah-Hartman 2019-11-11 20:10 ` Andreas Färber 2019-11-12 0:29 ` Andreas Färber 2019-11-12 5:23 ` Greg Kroah-Hartman 2019-11-12 7:29 ` Uwe Kleine-König 2019-11-12 10:47 ` Sense of soc bus? (was: [PATCH] base: soc: Export soc_device_to_device() helper) Andreas Färber 2019-11-14 22:09 ` Rob Herring 2019-11-15 11:15 ` Andreas Färber 2019-11-15 11:49 ` Andreas Färber [this message] 2019-11-15 8:52 ` Neil Armstrong 2019-11-15 8:58 ` Geert Uytterhoeven 2019-11-15 12:00 ` Andreas Färber 2019-11-15 12:34 ` Geert Uytterhoeven 2019-11-18 15:55 ` Tony Lindgren 2019-11-12 10:48 ` [PATCH] base: soc: Export soc_device_to_device() helper Lee Jones 2020-01-02 14:29 ` [RFC 02/11] soc: Add Realtek chip info driver for RTD1195 and RTD1295 James Tai 2020-01-02 14:39 ` Andreas Färber 2020-01-02 15:02 ` James Tai 2020-01-03 5:07 ` Stanley Chang[昌育德] 2019-11-03 1:36 ` [RFC 03/11] arm64: dts: realtek: rtd129x: Add chip info node Andreas Färber 2020-01-02 14:32 ` James Tai 2020-01-03 5:07 ` Stanley Chang[昌育德] 2020-01-02 14:33 ` James Tai 2020-01-02 14:34 ` James Tai 2019-11-03 1:36 ` [RFC 04/11] ARM: dts: rtd1195: " Andreas Färber 2019-11-03 1:36 ` [RFC 05/11] dt-bindings: soc: realtek: rtd1195-chip: Extend reg property Andreas Färber 2019-11-06 4:46 ` Rob Herring 2019-11-06 8:42 ` Andreas Färber 2019-11-03 1:36 ` [RFC 06/11] soc: realtek: chip: Detect RTD1296 Andreas Färber 2020-01-02 14:35 ` James Tai 2019-11-03 1:36 ` [RFC 07/11] arm64: dts: realtek: rtd129x: Extend chip-info reg with CHIP_INFO1 Andreas Färber 2019-11-03 1:36 ` [RFC 08/11] soc: realtek: chip: Detect RTD1293 Andreas Färber 2019-11-03 1:36 ` [RFC 09/11] dt-bindings: soc: realtek: rtd1195-chip: Extend reg node again Andreas Färber 2019-11-03 1:36 ` [RFC 10/11] soc: realtek: chip: Detect RTD1294 Andreas Färber 2019-11-03 1:36 ` [RFC 11/11] arm64: dts: realtek: rtd129x: Extend chip-info reg with efuse Andreas Färber 2019-11-07 7:16 ` [RFC 00/11] ARM: Realtek RTD1195/RTD1295 SoC info Andreas Färber
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=8411cceb-56f1-bcb3-96b6-5a2aaedd18cf@suse.de \ --to=afaerber@suse.de \ --cc=alexander.sverdlin@gmail.com \ --cc=bjorn.andersson@linaro.org \ --cc=boot-architecture@lists.linaro.org \ --cc=devicetree@vger.kernel.org \ --cc=festevam@gmail.com \ --cc=geert+renesas@glider.be \ --cc=gregkh@linuxfoundation.org \ --cc=hsweeten@visionengravers.com \ --cc=jonathanh@nvidia.com \ --cc=kernel@pengutronix.de \ --cc=khilman@baylibre.com \ --cc=lee.jones@linaro.org \ --cc=linus.walleij@linaro.org \ --cc=linux-amlogic@lists.infradead.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-imx@nxp.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-omap@vger.kernel.org \ --cc=linux-realtek-soc@lists.infradead.org \ --cc=linux-tegra@vger.kernel.org \ --cc=michal.simek@xilinx.com \ --cc=rafael@kernel.org \ --cc=robh@kernel.org \ --cc=s.hauer@pengutronix.de \ --cc=shawnguo@kernel.org \ --cc=thierry.reding@gmail.com \ --cc=tony@atomide.com \ --cc=u.kleine-koenig@pengutronix.de \ /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: link
LKML Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git git clone --mirror https://lore.kernel.org/lkml/7 lkml/git/7.git git clone --mirror https://lore.kernel.org/lkml/8 lkml/git/8.git git clone --mirror https://lore.kernel.org/lkml/9 lkml/git/9.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \ linux-kernel@vger.kernel.org public-inbox-index lkml Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git