From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 0/4] Introducing Exynos ChipId driver
Date: Tue, 06 May 2014 09:22:32 +0200 [thread overview]
Message-ID: <10277248.fmjBNTktBZ@wuerfel> (raw)
In-Reply-To: <CAL_JsqJXE4uXKA6XU1=3zFjdcEXHyUat2dL6wDKiZBx8S-p+Xg@mail.gmail.com>
On Monday 05 May 2014 10:34:02 Rob Herring wrote:
>
> > Ideally this should be done by slightly restructuring the DT
> > source to make all on-chip devices appear below the soc node.
> > We'd have to think a bit about how to best do this while
> > preserving compatibility with existing dts files.
>
> I don't agree. How is a block with chip ID info the parent of all the
> other devices?
>
> In doing some work to move default of_platform_populate out of
> platforms, I noticed that most platforms using the soc device are
> making it the parent of platform devices. I think this is either wrong
> or all platforms should have a default soc device. It makes little
> sense for some platforms to have a devices under a soc sysfs directory
> while others do not. Or the location changes when a platform latter
> adds the soc device.
We had a long discussion about this when we introduced the drivers/soc
framework. The intention is that the /sys/devices/soc* node is meant to
describe the SoC in its entirety, the same way you have a pci0000:00 node
as the root of all PCI devices of the first pci host bridge on a PC
system. This also reflects the reality of a SoC, which normally has one
bus that the CPU is connected to and that has all the other devices as
children.
Having the chipid registers as part of the top-level bus should not
be interpreted as having the other devices as children of the chipid
device, but rather the chipid registers as a property of the soc itself
as opposed to a random device that happens to be part of the soc.
Arnd
prev parent reply other threads:[~2014-05-06 7:22 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-03 6:11 [PATCH 0/4] Introducing Exynos ChipId driver Pankaj Dubey
2014-05-03 6:11 ` [PATCH 1/4] ARM: EXYNOS: remove soc_is_exynos4/5 from exynos.c Pankaj Dubey
2014-05-03 6:11 ` [PATCH 2/4] ARM: EXYNOS: remove unused header inclusion from hotplug.c Pankaj Dubey
2014-05-03 6:11 ` [PATCH 3/4] misc: exynos-chipid: Add Exynos Chipid driver support Pankaj Dubey
2014-05-05 7:57 ` Krzysztof Kozlowski
2014-05-05 9:28 ` Pankaj Dubey
2014-05-03 6:11 ` [PATCH 4/4] ARM: EXYNOS: Refactoring to remove soc_is_exynosXXXX macros from exynos Pankaj Dubey
2014-05-03 15:02 ` [PATCH 0/4] Introducing Exynos ChipId driver Arnd Bergmann
2014-05-05 9:23 ` Pankaj Dubey
2014-05-05 14:58 ` Arnd Bergmann
2014-05-05 15:01 ` Arnd Bergmann
2014-05-06 6:57 ` Pankaj Dubey
2014-05-06 7:24 ` Arnd Bergmann
2014-05-12 1:47 ` Olof Johansson
2014-05-12 9:47 ` Arnd Bergmann
2014-05-05 15:34 ` Rob Herring
2014-05-06 7:22 ` Arnd Bergmann [this message]
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=10277248.fmjBNTktBZ@wuerfel \
--to=arnd@arndb.de \
--cc=linux-arm-kernel@lists.infradead.org \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox