LKML Archive on
 help / color / Atom feed
From: "Andreas Färber" <>
To: Rob Herring <>
Cc: "Greg Kroah-Hartman" <>,
	"Uwe Kleine-König" <>,
	"Geert Uytterhoeven" <>,,
	"Tony Lindgren" <>,
	"Linus Walleij" <>,
	"Bjorn Andersson" <>,
	"Thierry Reding" <>,
	"Fabio Estevam" <>,
	"Kevin Hilman" <>,
	"Rafael J. Wysocki" <>,
	"Michal Simek" <>,
	"Jonathan Hunter" <>,
	"NXP Linux Team" <>,
	"Sascha Hauer" <>,
	"" <>,,
	"Lee Jones" <>,
	linux-omap <>,
	"Alexander Sverdlin" <>,
	LAKML <>,
	"" <>,
	"Hartley Sweeten" <>,
	"Pengutronix Kernel Team" <>,
	"Shawn Guo" <>,
	"Architecture Mailman List" <>,
	DTML <>
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: <> (raw)
In-Reply-To: <>

Am 14.11.19 um 23:09 schrieb Rob Herring:
> On Tue, Nov 12, 2019 at 4:47 AM Andreas Färber <> 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.


SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer
HRB 36809 (AG Nürnberg)

  parent reply index

Thread overview: 35+ 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
2019-11-03  1:36 ` [RFC 03/11] arm64: dts: realtek: rtd129x: Add chip info node Andreas Färber
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
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 publically 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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

LKML Archive on

Archives are clonable:
	git clone --mirror lkml/git/0.git
	git clone --mirror lkml/git/1.git
	git clone --mirror lkml/git/2.git
	git clone --mirror lkml/git/3.git
	git clone --mirror lkml/git/4.git
	git clone --mirror lkml/git/5.git
	git clone --mirror lkml/git/6.git
	git clone --mirror lkml/git/7.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/ \
	public-inbox-index lkml

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone