* [GIT PULL 1/3] ARM: tegra: rework PCIe regulators
@ 2014-06-23 21:23 Stephen Warren
2014-06-23 21:23 ` [GIT PULL 2/3] ARM: tegra: move fuse code out of arch/arm Stephen Warren
` (2 more replies)
0 siblings, 3 replies; 48+ messages in thread
From: Stephen Warren @ 2014-06-23 21:23 UTC (permalink / raw)
To: linux-arm-kernel
This branch reworks the set of regulators that the Tegra PCIe driver
uses, so that the driver and DT bindings more correctly model what's
really going on in HW.
I've made this a separate branch in case it needs to be pulled into the
PCIe tree to resolve any conflicts. Any branch that adds Tegra124
support to the PCIe driver will need to be based on this branch, and
such patches might show up for 3.17, and be taken through the ARM tree
so we can manage our own dependencies.
----------------------------------------------------------------
The following changes since commit 7171511eaec5bf23fb06078f59784a3a0626b38f:
Linux 3.16-rc1
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tegra-for-3.17-pcie-regulators
for you to fetch changes up to f4dfa465e03f0faf3f52d0e13a2a912c0998ddce:
ARM: tegra: Remove legacy PCIe power supply properties
----------------------------------------------------------------
Thierry Reding (5):
PCI: tegra: Overhaul regulator usage
ARM: tegra: Add new PCIe regulator properties
PCI: tegra: Implement accurate power supply scheme
PCI: tegra: Remove deprecated power supply properties
ARM: tegra: Remove legacy PCIe power supply properties
.../bindings/pci/nvidia,tegra20-pcie.txt | 30 +++-
arch/arm/boot/dts/tegra20-harmony.dts | 8 +-
arch/arm/boot/dts/tegra20-tamonten.dtsi | 7 +-
arch/arm/boot/dts/tegra20-trimslice.dts | 8 +-
arch/arm/boot/dts/tegra30-beaver.dts | 12 +-
arch/arm/boot/dts/tegra30-cardhu.dtsi | 11 +-
drivers/pci/host/pci-tegra.c | 148 +++++++++++--------
7 files changed, 148 insertions(+), 76 deletions(-)
^ permalink raw reply [flat|nested] 48+ messages in thread* [GIT PULL 2/3] ARM: tegra: move fuse code out of arch/arm 2014-06-23 21:23 [GIT PULL 1/3] ARM: tegra: rework PCIe regulators Stephen Warren @ 2014-06-23 21:23 ` Stephen Warren 2014-07-07 0:44 ` Olof Johansson 2014-06-23 21:23 ` [GIT PULL 3/3] ARM: tegra: use us counter as delay timer Stephen Warren 2014-07-07 0:38 ` [GIT PULL 1/3] ARM: tegra: rework PCIe regulators Olof Johansson 2 siblings, 1 reply; 48+ messages in thread From: Stephen Warren @ 2014-06-23 21:23 UTC (permalink / raw) To: linux-arm-kernel This branch moves code related to the Tegra fuses out of arch/arm and into a centralized location which could be shared with ARM64. It also adds support for reading the fuse data through sysfs. This is a separate branch because it will be a dependency for the upcoming XUSB padctrl driver, which is in turn a dependency for Tegra124 SATA, XHCI, and PCIe support. ---------------------------------------------------------------- The following changes since commit 7171511eaec5bf23fb06078f59784a3a0626b38f: Linux 3.16-rc1 are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tegra-for-3.17-fuse-move for you to fetch changes up to d97f79366c566b2986cf6a142eb4d04a6eb4e970: misc: fuse: fix dummy functions ---------------------------------------------------------------- Peter De Schrijver (6): ARM: tegra: export apb dma readl/writel ARM: tegra: move fuse exports to tegra-soc.h misc: fuse: Add efuse driver for Tegra ARM: tegra: Add efuse and apbmisc bindings ARM: tegra: build new fuse driver in drivers/misc misc: fuse: move APB DMA into Tegra20 fuse driver Stephen Warren (1): misc: fuse: fix dummy functions .../ABI/testing/sysfs-driver-tegra-fuse | 11 + .../bindings/fuse/nvidia,tegra20-fuse.txt | 40 +++ .../bindings/misc/nvidia,tegra20-apbmisc.txt | 13 + arch/arm/boot/dts/tegra114.dtsi | 15 ++ arch/arm/boot/dts/tegra124.dtsi | 15 ++ arch/arm/boot/dts/tegra20.dtsi | 15 ++ arch/arm/boot/dts/tegra30.dtsi | 15 ++ arch/arm/mach-tegra/Makefile | 5 - arch/arm/mach-tegra/apbio.c | 206 --------------- arch/arm/mach-tegra/apbio.h | 22 -- arch/arm/mach-tegra/cpuidle.c | 2 +- arch/arm/mach-tegra/flowctrl.c | 2 +- arch/arm/mach-tegra/fuse.c | 252 ------------------- arch/arm/mach-tegra/fuse.h | 79 ------ arch/arm/mach-tegra/hotplug.c | 2 +- arch/arm/mach-tegra/platsmp.c | 2 +- arch/arm/mach-tegra/pm.c | 2 +- arch/arm/mach-tegra/pmc.c | 2 +- arch/arm/mach-tegra/powergate.c | 2 +- arch/arm/mach-tegra/reset-handler.S | 2 +- arch/arm/mach-tegra/reset.c | 2 +- arch/arm/mach-tegra/sleep-tegra30.S | 2 +- arch/arm/mach-tegra/tegra.c | 7 +- drivers/misc/Makefile | 1 + drivers/misc/fuse/Makefile | 1 + drivers/misc/fuse/tegra/Makefile | 8 + drivers/misc/fuse/tegra/fuse-tegra.c | 154 ++++++++++++ drivers/misc/fuse/tegra/fuse-tegra20.c | 214 ++++++++++++++++ drivers/misc/fuse/tegra/fuse-tegra30.c | 223 ++++++++++++++++ drivers/misc/fuse/tegra/fuse.h | 71 ++++++ .../misc/fuse/tegra/speedo-tegra114.c | 53 ++-- drivers/misc/fuse/tegra/speedo-tegra124.c | 167 ++++++++++++ .../misc/fuse/tegra/speedo-tegra20.c | 42 ++-- .../misc/fuse/tegra/speedo-tegra30.c | 173 +++++++------ drivers/misc/fuse/tegra/tegra-apbmisc.c | 110 ++++++++ include/linux/tegra-soc.h | 42 ++++ 36 files changed, 1262 insertions(+), 712 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-driver-tegra-fuse create mode 100644 Documentation/devicetree/bindings/fuse/nvidia,tegra20-fuse.txt create mode 100644 Documentation/devicetree/bindings/misc/nvidia,tegra20-apbmisc.txt delete mode 100644 arch/arm/mach-tegra/apbio.c delete mode 100644 arch/arm/mach-tegra/apbio.h delete mode 100644 arch/arm/mach-tegra/fuse.c delete mode 100644 arch/arm/mach-tegra/fuse.h create mode 100644 drivers/misc/fuse/Makefile create mode 100644 drivers/misc/fuse/tegra/Makefile create mode 100644 drivers/misc/fuse/tegra/fuse-tegra.c create mode 100644 drivers/misc/fuse/tegra/fuse-tegra20.c create mode 100644 drivers/misc/fuse/tegra/fuse-tegra30.c create mode 100644 drivers/misc/fuse/tegra/fuse.h rename arch/arm/mach-tegra/tegra114_speedo.c => drivers/misc/fuse/tegra/speedo-tegra114.c (55%) create mode 100644 drivers/misc/fuse/tegra/speedo-tegra124.c rename arch/arm/mach-tegra/tegra20_speedo.c => drivers/misc/fuse/tegra/speedo-tegra20.c (67%) rename arch/arm/mach-tegra/tegra30_speedo.c => drivers/misc/fuse/tegra/speedo-tegra30.c (52%) create mode 100644 drivers/misc/fuse/tegra/tegra-apbmisc.c ^ permalink raw reply [flat|nested] 48+ messages in thread
* [GIT PULL 2/3] ARM: tegra: move fuse code out of arch/arm 2014-06-23 21:23 ` [GIT PULL 2/3] ARM: tegra: move fuse code out of arch/arm Stephen Warren @ 2014-07-07 0:44 ` Olof Johansson 2014-07-08 13:43 ` Peter De Schrijver 0 siblings, 1 reply; 48+ messages in thread From: Olof Johansson @ 2014-07-07 0:44 UTC (permalink / raw) To: linux-arm-kernel On Mon, Jun 23, 2014 at 03:23:45PM -0600, Stephen Warren wrote: > This branch moves code related to the Tegra fuses out of arch/arm and > into a centralized location which could be shared with ARM64. It also > adds support for reading the fuse data through sysfs. The new/moved misc driver isn't acked by any misc maintainer, so I can't take this branch. I saw no indication from searching the mailing list of that either, so it wasn't just a missed acked-by. I wonder if this code should go under drivers/soc/ instead? -Olof ^ permalink raw reply [flat|nested] 48+ messages in thread
* [GIT PULL 2/3] ARM: tegra: move fuse code out of arch/arm 2014-07-07 0:44 ` Olof Johansson @ 2014-07-08 13:43 ` Peter De Schrijver 2014-07-08 17:47 ` Olof Johansson 2014-07-18 2:44 ` Stephen Warren 0 siblings, 2 replies; 48+ messages in thread From: Peter De Schrijver @ 2014-07-08 13:43 UTC (permalink / raw) To: linux-arm-kernel On Mon, Jul 07, 2014 at 02:44:17AM +0200, Olof Johansson wrote: > On Mon, Jun 23, 2014 at 03:23:45PM -0600, Stephen Warren wrote: > > This branch moves code related to the Tegra fuses out of arch/arm and > > into a centralized location which could be shared with ARM64. It also > > adds support for reading the fuse data through sysfs. > > The new/moved misc driver isn't acked by any misc maintainer, so I can't > take this branch. > > I saw no indication from searching the mailing list of that either, > so it wasn't just a missed acked-by. > > I wonder if this code should go under drivers/soc/ instead? It's modelled after sunxi_sid.c which lives in drivers/misc/eeprom/. Originally this driver was also in drivers/misc/eeprom/, but Stephen objected and therefore it was moved to drivers/misc/fuse. I think that's the right place still. We anyway need this driver for sata and xhci. Cheers, Peter. ^ permalink raw reply [flat|nested] 48+ messages in thread
* [GIT PULL 2/3] ARM: tegra: move fuse code out of arch/arm 2014-07-08 13:43 ` Peter De Schrijver @ 2014-07-08 17:47 ` Olof Johansson 2014-07-09 11:16 ` Peter De Schrijver ` (2 more replies) 2014-07-18 2:44 ` Stephen Warren 1 sibling, 3 replies; 48+ messages in thread From: Olof Johansson @ 2014-07-08 17:47 UTC (permalink / raw) To: linux-arm-kernel On Tue, Jul 8, 2014 at 6:43 AM, Peter De Schrijver <pdeschrijver@nvidia.com> wrote: > On Mon, Jul 07, 2014 at 02:44:17AM +0200, Olof Johansson wrote: >> On Mon, Jun 23, 2014 at 03:23:45PM -0600, Stephen Warren wrote: >> > This branch moves code related to the Tegra fuses out of arch/arm and >> > into a centralized location which could be shared with ARM64. It also >> > adds support for reading the fuse data through sysfs. >> >> The new/moved misc driver isn't acked by any misc maintainer, so I can't >> take this branch. >> >> I saw no indication from searching the mailing list of that either, >> so it wasn't just a missed acked-by. >> >> I wonder if this code should go under drivers/soc/ instead? > > It's modelled after sunxi_sid.c which lives in drivers/misc/eeprom/. > Originally this driver was also in drivers/misc/eeprom/, but Stephen objected > and therefore it was moved to drivers/misc/fuse. I think that's the right > place still. I disagree, I think this belongs under drivers/soc. Especially since you're adding dependencies on this misc driver from other parts of the kernel / other drivers. I also don't like seeing init calls form platform code down into drivers/misc like you're adding here. Can you please look at doing that as a regular init call setup? The fact that you provide data to the rest of the kernel again really says drivers/soc to me, not drivers/misc. > We anyway need this driver for sata and xhci. Yes? -Olof ^ permalink raw reply [flat|nested] 48+ messages in thread
* [GIT PULL 2/3] ARM: tegra: move fuse code out of arch/arm 2014-07-08 17:47 ` Olof Johansson @ 2014-07-09 11:16 ` Peter De Schrijver 2014-07-09 12:50 ` Arnd Bergmann 2014-07-11 12:56 ` Thierry Reding 2014-07-18 2:45 ` Stephen Warren 2 siblings, 1 reply; 48+ messages in thread From: Peter De Schrijver @ 2014-07-09 11:16 UTC (permalink / raw) To: linux-arm-kernel On Tue, Jul 08, 2014 at 07:47:16PM +0200, Olof Johansson wrote: > On Tue, Jul 8, 2014 at 6:43 AM, Peter De Schrijver > <pdeschrijver@nvidia.com> wrote: > > On Mon, Jul 07, 2014 at 02:44:17AM +0200, Olof Johansson wrote: > >> On Mon, Jun 23, 2014 at 03:23:45PM -0600, Stephen Warren wrote: > >> > This branch moves code related to the Tegra fuses out of arch/arm and > >> > into a centralized location which could be shared with ARM64. It also > >> > adds support for reading the fuse data through sysfs. > >> > >> The new/moved misc driver isn't acked by any misc maintainer, so I can't > >> take this branch. > >> > >> I saw no indication from searching the mailing list of that either, > >> so it wasn't just a missed acked-by. > >> > >> I wonder if this code should go under drivers/soc/ instead? > > > > It's modelled after sunxi_sid.c which lives in drivers/misc/eeprom/. > > Originally this driver was also in drivers/misc/eeprom/, but Stephen objected > > and therefore it was moved to drivers/misc/fuse. I think that's the right > > place still. > > I disagree, I think this belongs under drivers/soc. Especially since > you're adding dependencies on this misc driver from other parts of the > kernel / other drivers. > There are several other drivers doing that already, eg: drivers/misc/eeprom/eeprom_93cx6.c drivers/misc/atmel-ssc.c drivers/misc/atmel_pwm.c > I also don't like seeing init calls form platform code down into > drivers/misc like you're adding here. Can you please look at doing > that as a regular init call setup? > Tegra has always avoided using the init calls and from previous versions of this patchset it's clear changing the init order is not an option for backwards compatibility reasons. Given that it seems to be impossible to reach consensus on what the exact behaviour should be, consider this patchset to be abandoned. Cheers, Peter. ^ permalink raw reply [flat|nested] 48+ messages in thread
* [GIT PULL 2/3] ARM: tegra: move fuse code out of arch/arm 2014-07-09 11:16 ` Peter De Schrijver @ 2014-07-09 12:50 ` Arnd Bergmann 0 siblings, 0 replies; 48+ messages in thread From: Arnd Bergmann @ 2014-07-09 12:50 UTC (permalink / raw) To: linux-arm-kernel On Wednesday 09 July 2014, Peter De Schrijver wrote: > On Tue, Jul 08, 2014 at 07:47:16PM +0200, Olof Johansson wrote: > > On Tue, Jul 8, 2014 at 6:43 AM, Peter De Schrijver > > <pdeschrijver@nvidia.com> wrote: > > > On Mon, Jul 07, 2014 at 02:44:17AM +0200, Olof Johansson wrote: > > >> On Mon, Jun 23, 2014 at 03:23:45PM -0600, Stephen Warren wrote: > > >> > This branch moves code related to the Tegra fuses out of arch/arm and > > >> > into a centralized location which could be shared with ARM64. It also > > >> > adds support for reading the fuse data through sysfs. > > >> > > >> The new/moved misc driver isn't acked by any misc maintainer, so I can't > > >> take this branch. > > >> > > >> I saw no indication from searching the mailing list of that either, > > >> so it wasn't just a missed acked-by. > > >> > > >> I wonder if this code should go under drivers/soc/ instead? > > > > > > It's modelled after sunxi_sid.c which lives in drivers/misc/eeprom/. > > > Originally this driver was also in drivers/misc/eeprom/, but Stephen objected > > > and therefore it was moved to drivers/misc/fuse. I think that's the right > > > place still. > > > > I disagree, I think this belongs under drivers/soc. Especially since > > you're adding dependencies on this misc driver from other parts of the > > kernel / other drivers. > > > > There are several other drivers doing that already, eg: > > drivers/misc/eeprom/eeprom_93cx6.c > drivers/misc/atmel-ssc.c > drivers/misc/atmel_pwm.c I believe we have plans to remove the latter two. I don't know about the eeprom one. Arnd ^ permalink raw reply [flat|nested] 48+ messages in thread
* [GIT PULL 2/3] ARM: tegra: move fuse code out of arch/arm 2014-07-08 17:47 ` Olof Johansson 2014-07-09 11:16 ` Peter De Schrijver @ 2014-07-11 12:56 ` Thierry Reding 2014-07-18 2:45 ` Stephen Warren 2 siblings, 0 replies; 48+ messages in thread From: Thierry Reding @ 2014-07-11 12:56 UTC (permalink / raw) To: linux-arm-kernel On Tue, Jul 08, 2014 at 10:47:16AM -0700, Olof Johansson wrote: > On Tue, Jul 8, 2014 at 6:43 AM, Peter De Schrijver > <pdeschrijver@nvidia.com> wrote: > > On Mon, Jul 07, 2014 at 02:44:17AM +0200, Olof Johansson wrote: > >> On Mon, Jun 23, 2014 at 03:23:45PM -0600, Stephen Warren wrote: > >> > This branch moves code related to the Tegra fuses out of arch/arm and > >> > into a centralized location which could be shared with ARM64. It also > >> > adds support for reading the fuse data through sysfs. > >> > >> The new/moved misc driver isn't acked by any misc maintainer, so I can't > >> take this branch. > >> > >> I saw no indication from searching the mailing list of that either, > >> so it wasn't just a missed acked-by. > >> > >> I wonder if this code should go under drivers/soc/ instead? > > > > It's modelled after sunxi_sid.c which lives in drivers/misc/eeprom/. > > Originally this driver was also in drivers/misc/eeprom/, but Stephen objected > > and therefore it was moved to drivers/misc/fuse. I think that's the right > > place still. > > I disagree, I think this belongs under drivers/soc. Especially since > you're adding dependencies on this misc driver from other parts of the > kernel / other drivers. > > I also don't like seeing init calls form platform code down into > drivers/misc like you're adding here. Can you please look at doing > that as a regular init call setup? > > The fact that you provide data to the rest of the kernel again really > says drivers/soc to me, not drivers/misc. Hi Olof, I just sent a patch series that addresses your comments: [PATCH 00/12] Add NVIDIA Tegra FUSE driver That contains a lot of the cleanup that I've been doing to get things ready for 64-bit. It's essentially what this pull request contained, with a couple of other patches on top to untangle the init sequence so that these can all go into regular init calls. I've tested on all four Tegra generations supported upstream. While there's possibly more that we can do I think it is a reasonable first step and I'd like to get this into 3.17 so that we can start moving out other things after the merge window. It would be great if you could have a look, and if there aren't any objections I'll send out another pull request. Thierry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140711/0c66808f/attachment.sig> ^ permalink raw reply [flat|nested] 48+ messages in thread
* [GIT PULL 2/3] ARM: tegra: move fuse code out of arch/arm 2014-07-08 17:47 ` Olof Johansson 2014-07-09 11:16 ` Peter De Schrijver 2014-07-11 12:56 ` Thierry Reding @ 2014-07-18 2:45 ` Stephen Warren 2014-07-18 5:33 ` Olof Johansson 2 siblings, 1 reply; 48+ messages in thread From: Stephen Warren @ 2014-07-18 2:45 UTC (permalink / raw) To: linux-arm-kernel On 07/08/2014 11:47 AM, Olof Johansson wrote: > On Tue, Jul 8, 2014 at 6:43 AM, Peter De Schrijver > <pdeschrijver@nvidia.com> wrote: >> On Mon, Jul 07, 2014 at 02:44:17AM +0200, Olof Johansson wrote: >>> On Mon, Jun 23, 2014 at 03:23:45PM -0600, Stephen Warren wrote: >>>> This branch moves code related to the Tegra fuses out of arch/arm and >>>> into a centralized location which could be shared with ARM64. It also >>>> adds support for reading the fuse data through sysfs. >>> >>> The new/moved misc driver isn't acked by any misc maintainer, so I can't >>> take this branch. >>> >>> I saw no indication from searching the mailing list of that either, >>> so it wasn't just a missed acked-by. >>> >>> I wonder if this code should go under drivers/soc/ instead? >> >> It's modelled after sunxi_sid.c which lives in drivers/misc/eeprom/. >> Originally this driver was also in drivers/misc/eeprom/, but Stephen objected >> and therefore it was moved to drivers/misc/fuse. I think that's the right >> place still. > > I disagree, I think this belongs under drivers/soc. Especially since > you're adding dependencies on this misc driver from other parts of the > kernel / other drivers. > > I also don't like seeing init calls form platform code down into > drivers/misc like you're adding here. Can you please look at doing > that as a regular init call setup? I strongly disagree with using init calls for this kind of thing. There are ordering dependencies between the initialization code that can only be sanely managed by explicitly calling functions in a particular order; there's simply no way to manage this using initcalls. This is exactly why the hooks in the ARM machine descriptors exist... ^ permalink raw reply [flat|nested] 48+ messages in thread
* [GIT PULL 2/3] ARM: tegra: move fuse code out of arch/arm 2014-07-18 2:45 ` Stephen Warren @ 2014-07-18 5:33 ` Olof Johansson 2014-07-21 15:06 ` Stephen Warren 0 siblings, 1 reply; 48+ messages in thread From: Olof Johansson @ 2014-07-18 5:33 UTC (permalink / raw) To: linux-arm-kernel On Thu, Jul 17, 2014 at 7:45 PM, Stephen Warren <swarren@wwwdotorg.org> wrote: > On 07/08/2014 11:47 AM, Olof Johansson wrote: >> On Tue, Jul 8, 2014 at 6:43 AM, Peter De Schrijver >> <pdeschrijver@nvidia.com> wrote: >>> On Mon, Jul 07, 2014 at 02:44:17AM +0200, Olof Johansson wrote: >>>> On Mon, Jun 23, 2014 at 03:23:45PM -0600, Stephen Warren wrote: >>>>> This branch moves code related to the Tegra fuses out of arch/arm and >>>>> into a centralized location which could be shared with ARM64. It also >>>>> adds support for reading the fuse data through sysfs. >>>> >>>> The new/moved misc driver isn't acked by any misc maintainer, so I can't >>>> take this branch. >>>> >>>> I saw no indication from searching the mailing list of that either, >>>> so it wasn't just a missed acked-by. >>>> >>>> I wonder if this code should go under drivers/soc/ instead? >>> >>> It's modelled after sunxi_sid.c which lives in drivers/misc/eeprom/. >>> Originally this driver was also in drivers/misc/eeprom/, but Stephen objected >>> and therefore it was moved to drivers/misc/fuse. I think that's the right >>> place still. >> >> I disagree, I think this belongs under drivers/soc. Especially since >> you're adding dependencies on this misc driver from other parts of the >> kernel / other drivers. >> >> I also don't like seeing init calls form platform code down into >> drivers/misc like you're adding here. Can you please look at doing >> that as a regular init call setup? > > I strongly disagree with using init calls for this kind of thing. There > are ordering dependencies between the initialization code that can only > be sanely managed by explicitly calling functions in a particular order; > there's simply no way to manage this using initcalls. This is exactly > why the hooks in the ARM machine descriptors exist... Right, but there are non on 64-bit, so you need to solve it for there anyway. And once it's solved there, you might as well keep it common with 32-bit. -Olof ^ permalink raw reply [flat|nested] 48+ messages in thread
* [GIT PULL 2/3] ARM: tegra: move fuse code out of arch/arm 2014-07-18 5:33 ` Olof Johansson @ 2014-07-21 15:06 ` Stephen Warren 2014-07-21 15:54 ` Catalin Marinas 0 siblings, 1 reply; 48+ messages in thread From: Stephen Warren @ 2014-07-21 15:06 UTC (permalink / raw) To: linux-arm-kernel On 07/17/2014 11:33 PM, Olof Johansson wrote: > On Thu, Jul 17, 2014 at 7:45 PM, Stephen Warren <swarren@wwwdotorg.org> wrote: >> On 07/08/2014 11:47 AM, Olof Johansson wrote: >>> On Tue, Jul 8, 2014 at 6:43 AM, Peter De Schrijver >>> <pdeschrijver@nvidia.com> wrote: >>>> On Mon, Jul 07, 2014 at 02:44:17AM +0200, Olof Johansson wrote: >>>>> On Mon, Jun 23, 2014 at 03:23:45PM -0600, Stephen Warren wrote: >>>>>> This branch moves code related to the Tegra fuses out of arch/arm and >>>>>> into a centralized location which could be shared with ARM64. It also >>>>>> adds support for reading the fuse data through sysfs. >>>>> >>>>> The new/moved misc driver isn't acked by any misc maintainer, so I can't >>>>> take this branch. >>>>> >>>>> I saw no indication from searching the mailing list of that either, >>>>> so it wasn't just a missed acked-by. >>>>> >>>>> I wonder if this code should go under drivers/soc/ instead? >>>> >>>> It's modelled after sunxi_sid.c which lives in drivers/misc/eeprom/. >>>> Originally this driver was also in drivers/misc/eeprom/, but Stephen objected >>>> and therefore it was moved to drivers/misc/fuse. I think that's the right >>>> place still. >>> >>> I disagree, I think this belongs under drivers/soc. Especially since >>> you're adding dependencies on this misc driver from other parts of the >>> kernel / other drivers. >>> >>> I also don't like seeing init calls form platform code down into >>> drivers/misc like you're adding here. Can you please look at doing >>> that as a regular init call setup? >> >> I strongly disagree with using init calls for this kind of thing. There >> are ordering dependencies between the initialization code that can only >> be sanely managed by explicitly calling functions in a particular order; >> there's simply no way to manage this using initcalls. This is exactly >> why the hooks in the ARM machine descriptors exist... > > Right, but there are non on 64-bit, so you need to solve it for there > anyway. And once it's solved there, you might as well keep it common > with 32-bit. My assertion is that we should just do it directly on 64-bit too. There's no reason for arm64 to deviate from what arch/arm does already. ^ permalink raw reply [flat|nested] 48+ messages in thread
* [GIT PULL 2/3] ARM: tegra: move fuse code out of arch/arm 2014-07-21 15:06 ` Stephen Warren @ 2014-07-21 15:54 ` Catalin Marinas 2014-07-21 16:14 ` Pawel Moll 2014-07-21 16:38 ` Stephen Warren 0 siblings, 2 replies; 48+ messages in thread From: Catalin Marinas @ 2014-07-21 15:54 UTC (permalink / raw) To: linux-arm-kernel On Mon, Jul 21, 2014 at 09:06:00AM -0600, Stephen Warren wrote: > On 07/17/2014 11:33 PM, Olof Johansson wrote: > > On Thu, Jul 17, 2014 at 7:45 PM, Stephen Warren <swarren@wwwdotorg.org> wrote: > >> On 07/08/2014 11:47 AM, Olof Johansson wrote: > >>> On Tue, Jul 8, 2014 at 6:43 AM, Peter De Schrijver > >>> <pdeschrijver@nvidia.com> wrote: > >>>> On Mon, Jul 07, 2014 at 02:44:17AM +0200, Olof Johansson wrote: > >>>>> On Mon, Jun 23, 2014 at 03:23:45PM -0600, Stephen Warren wrote: > >>>>>> This branch moves code related to the Tegra fuses out of arch/arm and > >>>>>> into a centralized location which could be shared with ARM64. It also > >>>>>> adds support for reading the fuse data through sysfs. > >>>>> > >>>>> The new/moved misc driver isn't acked by any misc maintainer, so I can't > >>>>> take this branch. > >>>>> > >>>>> I saw no indication from searching the mailing list of that either, > >>>>> so it wasn't just a missed acked-by. > >>>>> > >>>>> I wonder if this code should go under drivers/soc/ instead? > >>>> > >>>> It's modelled after sunxi_sid.c which lives in drivers/misc/eeprom/. > >>>> Originally this driver was also in drivers/misc/eeprom/, but Stephen objected > >>>> and therefore it was moved to drivers/misc/fuse. I think that's the right > >>>> place still. > >>> > >>> I disagree, I think this belongs under drivers/soc. Especially since > >>> you're adding dependencies on this misc driver from other parts of the > >>> kernel / other drivers. > >>> > >>> I also don't like seeing init calls form platform code down into > >>> drivers/misc like you're adding here. Can you please look at doing > >>> that as a regular init call setup? > >> > >> I strongly disagree with using init calls for this kind of thing. There > >> are ordering dependencies between the initialization code that can only > >> be sanely managed by explicitly calling functions in a particular order; > >> there's simply no way to manage this using initcalls. This is exactly > >> why the hooks in the ARM machine descriptors exist... > > > > Right, but there are non on 64-bit, so you need to solve it for there > > anyway. And once it's solved there, you might as well keep it common > > with 32-bit. > > My assertion is that we should just do it directly on 64-bit too. > There's no reason for arm64 to deviate from what arch/arm does already. On arm64, I really want to get away from any SoC specific early initcall. One of the main reason is for things like SCU, interconnects, system cache configurations (even certain clocks) to be enabled in firmware before Linux starts (it's an education process but that's a way for example to prevent people sending patches to enable SoC coherency because they haven't thought about it before upstreaming). It would be nice to be able to initialise SoC stuff at device_initcall() level (and even keep such code as modules in initramfs) but one of the problems we have is dependency on clocks (and the clock model which doesn't follow the device/driver model). The of_platform_populate() is called at arch_initcall_sync (after arch_initcall to still allow some SoC code, if needed, to run at arch_initcall). We have a similar issue with arm64 vexpress (well, just on the model) where vexpress_sysreg_init() is a core_initcall (should be fine as arch_initcall) as it needs to be done before of_platform_populate(). Pawel on cc should know more of the history here. I recall there were also some discussions about a SoC driver model which hangs off the top compatible string in the DT (e.g. "arm,vexpress") and allow (minimal) code to be run slightly earlier, though still not earlier than arch_initcall. -- Catalin ^ permalink raw reply [flat|nested] 48+ messages in thread
* [GIT PULL 2/3] ARM: tegra: move fuse code out of arch/arm 2014-07-21 15:54 ` Catalin Marinas @ 2014-07-21 16:14 ` Pawel Moll 2014-07-21 16:38 ` Stephen Warren 1 sibling, 0 replies; 48+ messages in thread From: Pawel Moll @ 2014-07-21 16:14 UTC (permalink / raw) To: linux-arm-kernel On Mon, 2014-07-21 at 16:54 +0100, Catalin Marinas wrote: > We have a similar issue with arm64 vexpress (well, just on the model) > where vexpress_sysreg_init() is a core_initcall (should be fine as > arch_initcall) as it needs to be done before of_platform_populate(). > Pawel on cc should know more of the history here. In case of vexpress the trick was to squeeze everything into the device model. Once this was done, there was enough initcall levels to get all dependencies sorted. The device model is good. We seemed to have learned to abuse it claiming that "things must be initialised early", while in 9 out of 10 cases they don't have to be "that early"... > I recall there were also some discussions about a SoC driver model which > hangs off the top compatible string in the DT (e.g. "arm,vexpress") and > allow (minimal) code to be run slightly earlier, though still not > earlier than arch_initcall. This was just a loose idea: http://thread.gmane.org/gmane.linux.ports.arm.kernel/204361/focus=204843 I still like it, and it seems logical to me. We've got a platform. It's got a compatible string. We can write a driver for this platform that does all magic at appropriate initcall level. Pawe? ^ permalink raw reply [flat|nested] 48+ messages in thread
* [GIT PULL 2/3] ARM: tegra: move fuse code out of arch/arm 2014-07-21 15:54 ` Catalin Marinas 2014-07-21 16:14 ` Pawel Moll @ 2014-07-21 16:38 ` Stephen Warren 2014-07-21 16:46 ` Olof Johansson 2014-07-22 11:26 ` Catalin Marinas 1 sibling, 2 replies; 48+ messages in thread From: Stephen Warren @ 2014-07-21 16:38 UTC (permalink / raw) To: linux-arm-kernel On 07/21/2014 09:54 AM, Catalin Marinas wrote: > On Mon, Jul 21, 2014 at 09:06:00AM -0600, Stephen Warren wrote: >> On 07/17/2014 11:33 PM, Olof Johansson wrote: >>> On Thu, Jul 17, 2014 at 7:45 PM, Stephen Warren <swarren@wwwdotorg.org> wrote: >>>> On 07/08/2014 11:47 AM, Olof Johansson wrote: >>>>> On Tue, Jul 8, 2014 at 6:43 AM, Peter De Schrijver >>>>> <pdeschrijver@nvidia.com> wrote: >>>>>> On Mon, Jul 07, 2014 at 02:44:17AM +0200, Olof Johansson wrote: >>>>>>> On Mon, Jun 23, 2014 at 03:23:45PM -0600, Stephen Warren wrote: >>>>>>>> This branch moves code related to the Tegra fuses out of arch/arm and >>>>>>>> into a centralized location which could be shared with ARM64. It also >>>>>>>> adds support for reading the fuse data through sysfs. >>>>>>> >>>>>>> The new/moved misc driver isn't acked by any misc maintainer, so I can't >>>>>>> take this branch. >>>>>>> >>>>>>> I saw no indication from searching the mailing list of that either, >>>>>>> so it wasn't just a missed acked-by. >>>>>>> >>>>>>> I wonder if this code should go under drivers/soc/ instead? >>>>>> >>>>>> It's modelled after sunxi_sid.c which lives in drivers/misc/eeprom/. >>>>>> Originally this driver was also in drivers/misc/eeprom/, but Stephen objected >>>>>> and therefore it was moved to drivers/misc/fuse. I think that's the right >>>>>> place still. >>>>> >>>>> I disagree, I think this belongs under drivers/soc. Especially since >>>>> you're adding dependencies on this misc driver from other parts of the >>>>> kernel / other drivers. >>>>> >>>>> I also don't like seeing init calls form platform code down into >>>>> drivers/misc like you're adding here. Can you please look at doing >>>>> that as a regular init call setup? >>>> >>>> I strongly disagree with using init calls for this kind of thing. There >>>> are ordering dependencies between the initialization code that can only >>>> be sanely managed by explicitly calling functions in a particular order; >>>> there's simply no way to manage this using initcalls. This is exactly >>>> why the hooks in the ARM machine descriptors exist... >>> >>> Right, but there are non on 64-bit, so you need to solve it for there >>> anyway. And once it's solved there, you might as well keep it common >>> with 32-bit. >> >> My assertion is that we should just do it directly on 64-bit too. >> There's no reason for arm64 to deviate from what arch/arm does already. > > On arm64, I really want to get away from any SoC specific early > initcall. One of the main reason is for things like SCU, interconnects, > system cache configurations (even certain clocks) to be enabled in > firmware before Linux starts (it's an education process but that's a way > for example to prevent people sending patches to enable SoC coherency > because they haven't thought about it before upstreaming). > > It would be nice to be able to initialise SoC stuff at device_initcall() > level (and even keep such code as modules in initramfs) but one of the > problems we have is dependency on clocks (and the clock model which > doesn't follow the device/driver model). The of_platform_populate() is > called at arch_initcall_sync (after arch_initcall to still allow some > SoC code, if needed, to run at arch_initcall). The main thing I want to avoid is a ton of separate drivers that all rely on each-other getting resolved by deferred probe. While that might work out, it seems pointless to make the kernel try and probe a bunch of stuff just to have it fail and get repeated, when we know exactly which order everything should get initialized in. Another issue is that we have SoCs which only differ in the CPU. I want the code to work identically on both SoCs so the CPU has limited affect on the low-level IO code. If we're going to enforce a "no machine descriptors" rule on arch/arm64, I think we should do the same thing in arch/arm for consistency. > We have a similar issue with arm64 vexpress (well, just on the model) > where vexpress_sysreg_init() is a core_initcall (should be fine as > arch_initcall) as it needs to be done before of_platform_populate(). > Pawel on cc should know more of the history here. > > I recall there were also some discussions about a SoC driver model which > hangs off the top compatible string in the DT (e.g. "arm,vexpress") and > allow (minimal) code to be run slightly earlier, though still not > earlier than arch_initcall. I guess that would work out OK; if we force the driver that binds to a top-level compatible value of "nvidia,tegraNNN" to probe first, and it then calls out to all the low-level init code in a sane order, that would solve the problem. I'm not sure that's any better than having a machine descriptor with an "init" function though; wrapping all this in a driver just seems like overhead, but it would work out OK. ^ permalink raw reply [flat|nested] 48+ messages in thread
* [GIT PULL 2/3] ARM: tegra: move fuse code out of arch/arm 2014-07-21 16:38 ` Stephen Warren @ 2014-07-21 16:46 ` Olof Johansson 2014-07-21 17:00 ` [PATCH] platform: Make platform_bus device a platform device Pawel Moll 2014-07-22 10:27 ` [GIT PULL 2/3] ARM: tegra: move fuse code out of arch/arm Catalin Marinas 2014-07-22 11:26 ` Catalin Marinas 1 sibling, 2 replies; 48+ messages in thread From: Olof Johansson @ 2014-07-21 16:46 UTC (permalink / raw) To: linux-arm-kernel On Mon, Jul 21, 2014 at 9:38 AM, Stephen Warren <swarren@wwwdotorg.org> wrote: > On 07/21/2014 09:54 AM, Catalin Marinas wrote: >> On Mon, Jul 21, 2014 at 09:06:00AM -0600, Stephen Warren wrote: >>> On 07/17/2014 11:33 PM, Olof Johansson wrote: >>>> On Thu, Jul 17, 2014 at 7:45 PM, Stephen Warren <swarren@wwwdotorg.org> wrote: >>>>> On 07/08/2014 11:47 AM, Olof Johansson wrote: >>>>>> On Tue, Jul 8, 2014 at 6:43 AM, Peter De Schrijver >>>>>> <pdeschrijver@nvidia.com> wrote: >>>>>>> On Mon, Jul 07, 2014 at 02:44:17AM +0200, Olof Johansson wrote: >>>>>>>> On Mon, Jun 23, 2014 at 03:23:45PM -0600, Stephen Warren wrote: >>>>>>>>> This branch moves code related to the Tegra fuses out of arch/arm and >>>>>>>>> into a centralized location which could be shared with ARM64. It also >>>>>>>>> adds support for reading the fuse data through sysfs. >>>>>>>> >>>>>>>> The new/moved misc driver isn't acked by any misc maintainer, so I can't >>>>>>>> take this branch. >>>>>>>> >>>>>>>> I saw no indication from searching the mailing list of that either, >>>>>>>> so it wasn't just a missed acked-by. >>>>>>>> >>>>>>>> I wonder if this code should go under drivers/soc/ instead? >>>>>>> >>>>>>> It's modelled after sunxi_sid.c which lives in drivers/misc/eeprom/. >>>>>>> Originally this driver was also in drivers/misc/eeprom/, but Stephen objected >>>>>>> and therefore it was moved to drivers/misc/fuse. I think that's the right >>>>>>> place still. >>>>>> >>>>>> I disagree, I think this belongs under drivers/soc. Especially since >>>>>> you're adding dependencies on this misc driver from other parts of the >>>>>> kernel / other drivers. >>>>>> >>>>>> I also don't like seeing init calls form platform code down into >>>>>> drivers/misc like you're adding here. Can you please look at doing >>>>>> that as a regular init call setup? >>>>> >>>>> I strongly disagree with using init calls for this kind of thing. There >>>>> are ordering dependencies between the initialization code that can only >>>>> be sanely managed by explicitly calling functions in a particular order; >>>>> there's simply no way to manage this using initcalls. This is exactly >>>>> why the hooks in the ARM machine descriptors exist... >>>> >>>> Right, but there are non on 64-bit, so you need to solve it for there >>>> anyway. And once it's solved there, you might as well keep it common >>>> with 32-bit. >>> >>> My assertion is that we should just do it directly on 64-bit too. >>> There's no reason for arm64 to deviate from what arch/arm does already. >> >> On arm64, I really want to get away from any SoC specific early >> initcall. One of the main reason is for things like SCU, interconnects, >> system cache configurations (even certain clocks) to be enabled in >> firmware before Linux starts (it's an education process but that's a way >> for example to prevent people sending patches to enable SoC coherency >> because they haven't thought about it before upstreaming). >> >> It would be nice to be able to initialise SoC stuff at device_initcall() >> level (and even keep such code as modules in initramfs) but one of the >> problems we have is dependency on clocks (and the clock model which >> doesn't follow the device/driver model). The of_platform_populate() is >> called at arch_initcall_sync (after arch_initcall to still allow some >> SoC code, if needed, to run at arch_initcall). > > The main thing I want to avoid is a ton of separate drivers that all > rely on each-other getting resolved by deferred probe. While that might > work out, it seems pointless to make the kernel try and probe a bunch of > stuff just to have it fail and get repeated, when we know exactly which > order everything should get initialized in. > > Another issue is that we have SoCs which only differ in the CPU. I want > the code to work identically on both SoCs so the CPU has limited affect > on the low-level IO code. If we're going to enforce a "no machine > descriptors" rule on arch/arm64, I think we should do the same thing in > arch/arm for consistency. > >> We have a similar issue with arm64 vexpress (well, just on the model) >> where vexpress_sysreg_init() is a core_initcall (should be fine as >> arch_initcall) as it needs to be done before of_platform_populate(). >> Pawel on cc should know more of the history here. >> >> I recall there were also some discussions about a SoC driver model which >> hangs off the top compatible string in the DT (e.g. "arm,vexpress") and >> allow (minimal) code to be run slightly earlier, though still not >> earlier than arch_initcall. > > I guess that would work out OK; if we force the driver that binds to a > top-level compatible value of "nvidia,tegraNNN" to probe first, and it > then calls out to all the low-level init code in a sane order, that > would solve the problem. I'm not sure that's any better than having a > machine descriptor with an "init" function though; wrapping all this in > a driver just seems like overhead, but it would work out OK. This is exactly the same as having a machine descriptor, but the arch/arm64 maintainers don't have to look at it so they don't think it is one. So now we need to find a place for machine descriptors somewhere under drivers/* too. Sigh. Agreed, this is nothing but overhead and overabstraction. -Olof ^ permalink raw reply [flat|nested] 48+ messages in thread
* [PATCH] platform: Make platform_bus device a platform device 2014-07-21 16:46 ` Olof Johansson @ 2014-07-21 17:00 ` Pawel Moll 2014-07-21 18:40 ` Greg Kroah-Hartman 2014-07-22 10:27 ` [GIT PULL 2/3] ARM: tegra: move fuse code out of arch/arm Catalin Marinas 1 sibling, 1 reply; 48+ messages in thread From: Pawel Moll @ 2014-07-21 17:00 UTC (permalink / raw) To: linux-arm-kernel ... describing the root of the device tree, so one can write a platform driver initializing the platform. Signed-off-by: Pawel Moll <pawel.moll@arm.com> --- For what it's worth, the patch I came up back then. *Untested* against current head... arch/arm/mach-imx/devices/devices.c | 4 ++-- arch/unicore32/kernel/puv3-core.c | 2 +- arch/unicore32/kernel/puv3-nb0916.c | 6 +++--- drivers/base/platform.c | 18 ++++++++++++------ drivers/char/tile-srom.c | 2 +- drivers/mmc/host/sdhci-pltfm.c | 2 +- drivers/scsi/hosts.c | 2 +- include/linux/platform_device.h | 2 +- 8 files changed, 22 insertions(+), 16 deletions(-) diff --git a/arch/arm/mach-imx/devices/devices.c b/arch/arm/mach-imx/devices/devices.c index 1b4366a..48c3817 100644 --- a/arch/arm/mach-imx/devices/devices.c +++ b/arch/arm/mach-imx/devices/devices.c @@ -24,12 +24,12 @@ struct device mxc_aips_bus = { .init_name = "mxc_aips", - .parent = &platform_bus, + .parent = &platform_bus.dev, }; struct device mxc_ahb_bus = { .init_name = "mxc_ahb", - .parent = &platform_bus, + .parent = &platform_bus.dev, }; int __init mxc_device_init(void) diff --git a/arch/unicore32/kernel/puv3-core.c b/arch/unicore32/kernel/puv3-core.c index 254adee..28d1387 100644 --- a/arch/unicore32/kernel/puv3-core.c +++ b/arch/unicore32/kernel/puv3-core.c @@ -272,7 +272,7 @@ void __init puv3_core_init(void) platform_device_register_simple("PKUnity-v3-UART", 1, puv3_uart1_resources, ARRAY_SIZE(puv3_uart1_resources)); platform_device_register_simple("PKUnity-v3-AC97", -1, NULL, 0); - platform_device_register_resndata(&platform_bus, "musb_hdrc", -1, + platform_device_register_resndata(&platform_bus.dev, "musb_hdrc", -1, puv3_usb_resources, ARRAY_SIZE(puv3_usb_resources), &puv3_usb_plat, sizeof(puv3_usb_plat)); } diff --git a/arch/unicore32/kernel/puv3-nb0916.c b/arch/unicore32/kernel/puv3-nb0916.c index 0c6618e..4b1c462 100644 --- a/arch/unicore32/kernel/puv3-nb0916.c +++ b/arch/unicore32/kernel/puv3-nb0916.c @@ -112,13 +112,13 @@ int __init mach_nb0916_init(void) platform_device_register_simple("PKUnity-v3-I2C", -1, puv3_i2c_resources, ARRAY_SIZE(puv3_i2c_resources)); - platform_device_register_data(&platform_bus, "pwm-backlight", -1, + platform_device_register_data(&platform_bus.dev, "pwm-backlight", -1, &nb0916_backlight_data, sizeof(nb0916_backlight_data)); - platform_device_register_data(&platform_bus, "gpio-keys", -1, + platform_device_register_data(&platform_bus.dev, "gpio-keys", -1, &nb0916_gpio_button_data, sizeof(nb0916_gpio_button_data)); - platform_device_register_resndata(&platform_bus, "physmap-flash", -1, + platform_device_register_resndata(&platform_bus.dev, "physmap-flash", -1, &physmap_flash_resource, 1, &physmap_flash_data, sizeof(physmap_flash_data)); diff --git a/drivers/base/platform.c b/drivers/base/platform.c index eee48c4..cb69b38 100644 --- a/drivers/base/platform.c +++ b/drivers/base/platform.c @@ -30,8 +30,8 @@ /* For automatically allocated device IDs */ static DEFINE_IDA(platform_devid_ida); -struct device platform_bus = { - .init_name = "platform", +struct platform_device platform_bus = { + .name = "platform", }; EXPORT_SYMBOL_GPL(platform_bus); @@ -300,7 +300,7 @@ int platform_device_add(struct platform_device *pdev) return -EINVAL; if (!pdev->dev.parent) - pdev->dev.parent = &platform_bus; + pdev->dev.parent = &platform_bus.dev; pdev->dev.bus = &platform_bus_type; @@ -946,12 +946,18 @@ int __init platform_bus_init(void) early_platform_cleanup(); - error = device_register(&platform_bus); + dev_set_name(&platform_bus.dev, "%s", platform_bus.name); + error = device_register(&platform_bus.name); if (error) return error; error = bus_register(&platform_bus_type); - if (error) - device_unregister(&platform_bus); + if (!error) { + platform_bus.dev.of_node = allnodes; + platform_bus.dev.bus = &platform_bus_type; + bus_add_device(&platform_bus.dev); + } else { + device_unregister(&platform_bus.dev); + } return error; } diff --git a/drivers/char/tile-srom.c b/drivers/char/tile-srom.c index bd37747..4e4b7a2 100644 --- a/drivers/char/tile-srom.c +++ b/drivers/char/tile-srom.c @@ -350,7 +350,7 @@ static int srom_setup_minor(struct srom_dev *srom, int index) SROM_PAGE_SIZE_OFF, sizeof(srom->page_size)) < 0) return -EIO; - dev = device_create(srom_class, &platform_bus, + dev = device_create(srom_class, &platform_bus.dev, MKDEV(srom_major, index), srom, "%d", index); return PTR_ERR_OR_ZERO(dev); } diff --git a/drivers/mmc/host/sdhci-pltfm.c b/drivers/mmc/host/sdhci-pltfm.c index 7e834fb..9a2b0d0 100644 --- a/drivers/mmc/host/sdhci-pltfm.c +++ b/drivers/mmc/host/sdhci-pltfm.c @@ -137,7 +137,7 @@ struct sdhci_host *sdhci_pltfm_init(struct platform_device *pdev, dev_err(&pdev->dev, "Invalid iomem size!\n"); /* Some PCI-based MFD need the parent here */ - if (pdev->dev.parent != &platform_bus && !np) + if (pdev->dev.parent != &platform_bus.dev && !np) host = sdhci_alloc_host(pdev->dev.parent, sizeof(struct sdhci_pltfm_host) + priv_size); else diff --git a/drivers/scsi/hosts.c b/drivers/scsi/hosts.c index 3cbb57a..c14c36f 100644 --- a/drivers/scsi/hosts.c +++ b/drivers/scsi/hosts.c @@ -218,7 +218,7 @@ int scsi_add_host_with_dma(struct Scsi_Host *shost, struct device *dev, goto fail; if (!shost->shost_gendev.parent) - shost->shost_gendev.parent = dev ? dev : &platform_bus; + shost->shost_gendev.parent = dev ? dev : &platform_bus.dev; if (!dma_dev) dma_dev = shost->shost_gendev.parent; diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h index 16f6654..a99032a 100644 --- a/include/linux/platform_device.h +++ b/include/linux/platform_device.h @@ -44,7 +44,7 @@ extern int platform_device_register(struct platform_device *); extern void platform_device_unregister(struct platform_device *); extern struct bus_type platform_bus_type; -extern struct device platform_bus; +extern struct platform_device platform_bus; extern void arch_setup_pdev_archdata(struct platform_device *); extern struct resource *platform_get_resource(struct platform_device *, -- 1.9.1 ^ permalink raw reply related [flat|nested] 48+ messages in thread
* [PATCH] platform: Make platform_bus device a platform device 2014-07-21 17:00 ` [PATCH] platform: Make platform_bus device a platform device Pawel Moll @ 2014-07-21 18:40 ` Greg Kroah-Hartman 2014-07-22 10:02 ` [PATCH v2] " Pawel Moll 0 siblings, 1 reply; 48+ messages in thread From: Greg Kroah-Hartman @ 2014-07-21 18:40 UTC (permalink / raw) To: linux-arm-kernel On Mon, Jul 21, 2014 at 06:00:34PM +0100, Pawel Moll wrote: > ... describing the root of the device tree, so one can write > a platform driver initializing the platform. > > Signed-off-by: Pawel Moll <pawel.moll@arm.com> > --- > > For what it's worth, the patch I came up back then. > *Untested* against current head... I like the idea, nice... ^ permalink raw reply [flat|nested] 48+ messages in thread
* [PATCH v2] platform: Make platform_bus device a platform device 2014-07-21 18:40 ` Greg Kroah-Hartman @ 2014-07-22 10:02 ` Pawel Moll 2014-07-22 17:10 ` Greg Kroah-Hartman 0 siblings, 1 reply; 48+ messages in thread From: Pawel Moll @ 2014-07-22 10:02 UTC (permalink / raw) To: linux-arm-kernel ... describing the root of the device tree, so one can write a platform driver initializing the platform. All references to platform_bus device have been fixed up, although in most cases they could be simply removed or replaced by NULL (platform devices with no parent are adopted by main platform_bus device automagically). Signed-off-by: Pawel Moll <pawel.moll@arm.com> --- Changes since v1: * rebase on top of v3.16-rc6 * fixed up all new explicit references to platform_bus, with majority in mach-shmobile; 99% of them seem completely useless and I was *very* tempted to replace them with NULL - all reasons for and against this are welcomed arch/arm/mach-bcm/board_bcm21664.c | 2 +- arch/arm/mach-bcm/board_bcm281xx.c | 2 +- arch/arm/mach-clps711x/board-edb7211.c | 6 ++--- arch/arm/mach-clps711x/board-p720t.c | 6 ++--- arch/arm/mach-imx/devices/devices.c | 4 ++-- arch/arm/mach-imx/mach-mx27ads.c | 2 +- arch/arm/mach-shmobile/board-ape6evm.c | 14 ++++++------ arch/arm/mach-shmobile/board-bockw.c | 22 +++++++++--------- arch/arm/mach-shmobile/board-genmai.c | 6 ++--- arch/arm/mach-shmobile/board-koelsch.c | 28 +++++++++++------------ arch/arm/mach-shmobile/board-lager.c | 40 ++++++++++++++++----------------- arch/arm/mach-shmobile/board-marzen.c | 2 +- arch/arm/mach-shmobile/setup-r7s72100.c | 2 +- arch/arm/mach-shmobile/setup-r8a73a4.c | 8 +++---- arch/arm/mach-shmobile/setup-r8a7778.c | 14 ++++++------ arch/arm/mach-shmobile/setup-r8a7779.c | 6 ++--- arch/arm/mach-shmobile/setup-r8a7790.c | 10 ++++----- arch/arm/mach-shmobile/setup-r8a7791.c | 8 +++---- arch/unicore32/kernel/puv3-core.c | 2 +- arch/unicore32/kernel/puv3-nb0916.c | 6 ++--- drivers/base/platform.c | 18 ++++++++++----- drivers/char/tile-srom.c | 2 +- drivers/mmc/host/sdhci-pltfm.c | 2 +- drivers/scsi/hosts.c | 2 +- include/linux/platform_device.h | 2 +- 25 files changed, 111 insertions(+), 105 deletions(-) diff --git a/arch/arm/mach-bcm/board_bcm21664.c b/arch/arm/mach-bcm/board_bcm21664.c index f0521cc..310dae9 100644 --- a/arch/arm/mach-bcm/board_bcm21664.c +++ b/arch/arm/mach-bcm/board_bcm21664.c @@ -61,7 +61,7 @@ static void bcm21664_restart(enum reboot_mode mode, const char *cmd) static void __init bcm21664_init(void) { of_platform_populate(NULL, of_default_bus_match_table, NULL, - &platform_bus); + &platform_bus.dev); kona_l2_cache_init(); } diff --git a/arch/arm/mach-bcm/board_bcm281xx.c b/arch/arm/mach-bcm/board_bcm281xx.c index 1ac59fc..00aa22a 100644 --- a/arch/arm/mach-bcm/board_bcm281xx.c +++ b/arch/arm/mach-bcm/board_bcm281xx.c @@ -59,7 +59,7 @@ static void bcm281xx_restart(enum reboot_mode mode, const char *cmd) static void __init bcm281xx_init(void) { of_platform_populate(NULL, of_default_bus_match_table, NULL, - &platform_bus); + &platform_bus.dev); kona_l2_cache_init(); } diff --git a/arch/arm/mach-clps711x/board-edb7211.c b/arch/arm/mach-clps711x/board-edb7211.c index f9828f8..425a00b 100644 --- a/arch/arm/mach-clps711x/board-edb7211.c +++ b/arch/arm/mach-clps711x/board-edb7211.c @@ -158,16 +158,16 @@ static void __init edb7211_init_late(void) gpio_request_array(edb7211_gpios, ARRAY_SIZE(edb7211_gpios)); platform_device_register(&edb7211_flash_pdev); - platform_device_register_data(&platform_bus, "platform-lcd", 0, + platform_device_register_data(&platform_bus.dev, "platform-lcd", 0, &edb7211_lcd_power_pdata, sizeof(edb7211_lcd_power_pdata)); - platform_device_register_data(&platform_bus, "generic-bl", 0, + platform_device_register_data(&platform_bus.dev, "generic-bl", 0, &edb7211_lcd_backlight_pdata, sizeof(edb7211_lcd_backlight_pdata)); platform_device_register_simple("video-clps711x", 0, NULL, 0); platform_device_register_simple("cs89x0", 0, edb7211_cs8900_resource, ARRAY_SIZE(edb7211_cs8900_resource)); - platform_device_register_data(&platform_bus, "i2c-gpio", 0, + platform_device_register_data(&platform_bus.dev, "i2c-gpio", 0, &edb7211_i2c_pdata, sizeof(edb7211_i2c_pdata)); } diff --git a/arch/arm/mach-clps711x/board-p720t.c b/arch/arm/mach-clps711x/board-p720t.c index 0cf0e51..70423c2 100644 --- a/arch/arm/mach-clps711x/board-p720t.c +++ b/arch/arm/mach-clps711x/board-p720t.c @@ -348,14 +348,14 @@ static void __init p720t_init_late(void) { WARN_ON(gpio_request_array(p720t_gpios, ARRAY_SIZE(p720t_gpios))); - platform_device_register_data(&platform_bus, "platform-lcd", 0, + platform_device_register_data(&platform_bus.dev, "platform-lcd", 0, &p720t_lcd_power_pdata, sizeof(p720t_lcd_power_pdata)); - platform_device_register_data(&platform_bus, "generic-bl", 0, + platform_device_register_data(&platform_bus.dev, "generic-bl", 0, &p720t_lcd_backlight_pdata, sizeof(p720t_lcd_backlight_pdata)); platform_device_register_simple("video-clps711x", 0, NULL, 0); - platform_device_register_data(&platform_bus, "leds-gpio", 0, + platform_device_register_data(&platform_bus.dev, "leds-gpio", 0, &p720t_gpio_led_pdata, sizeof(p720t_gpio_led_pdata)); } diff --git a/arch/arm/mach-imx/devices/devices.c b/arch/arm/mach-imx/devices/devices.c index 1b4366a..48c3817 100644 --- a/arch/arm/mach-imx/devices/devices.c +++ b/arch/arm/mach-imx/devices/devices.c @@ -24,12 +24,12 @@ struct device mxc_aips_bus = { .init_name = "mxc_aips", - .parent = &platform_bus, + .parent = &platform_bus.dev, }; struct device mxc_ahb_bus = { .init_name = "mxc_ahb", - .parent = &platform_bus, + .parent = &platform_bus.dev, }; int __init mxc_device_init(void) diff --git a/arch/arm/mach-imx/mach-mx27ads.c b/arch/arm/mach-imx/mach-mx27ads.c index 2f834ce..e8e50d0 100644 --- a/arch/arm/mach-imx/mach-mx27ads.c +++ b/arch/arm/mach-imx/mach-mx27ads.c @@ -245,7 +245,7 @@ static void __init mx27ads_regulator_init(void) vchip->set = vgpio_set; gpiochip_add(vchip); - platform_device_register_data(&platform_bus, "reg-fixed-voltage", + platform_device_register_data(&platform_bus.dev, "reg-fixed-voltage", PLATFORM_DEVID_AUTO, &mx27ads_lcd_regulator_pdata, sizeof(mx27ads_lcd_regulator_pdata)); diff --git a/arch/arm/mach-shmobile/board-ape6evm.c b/arch/arm/mach-shmobile/board-ape6evm.c index fe071a9..f132d8a 100644 --- a/arch/arm/mach-shmobile/board-ape6evm.c +++ b/arch/arm/mach-shmobile/board-ape6evm.c @@ -248,29 +248,29 @@ static void __init ape6evm_add_standard_devices(void) regulator_register_fixed(0, dummy_supplies, ARRAY_SIZE(dummy_supplies)); - platform_device_register_resndata(&platform_bus, "smsc911x", -1, + platform_device_register_resndata(&platform_bus.dev, "smsc911x", -1, lan9220_res, ARRAY_SIZE(lan9220_res), &lan9220_data, sizeof(lan9220_data)); regulator_register_always_on(1, "MMC0 Vcc", vcc_mmc0_consumers, ARRAY_SIZE(vcc_mmc0_consumers), 2800000); - platform_device_register_resndata(&platform_bus, "sh_mmcif", 0, + platform_device_register_resndata(&platform_bus.dev, "sh_mmcif", 0, mmcif0_resources, ARRAY_SIZE(mmcif0_resources), &mmcif0_pdata, sizeof(mmcif0_pdata)); - platform_device_register_data(&platform_bus, "reg-fixed-voltage", 2, + platform_device_register_data(&platform_bus.dev, "reg-fixed-voltage", 2, &vcc_sdhi0_info, sizeof(vcc_sdhi0_info)); - platform_device_register_resndata(&platform_bus, "sh_mobile_sdhi", 0, + platform_device_register_resndata(&platform_bus.dev, "sh_mobile_sdhi", 0, sdhi0_resources, ARRAY_SIZE(sdhi0_resources), &sdhi0_pdata, sizeof(sdhi0_pdata)); regulator_register_always_on(3, "SDHI1 Vcc", vcc_sdhi1_consumers, ARRAY_SIZE(vcc_sdhi1_consumers), 3300000); - platform_device_register_resndata(&platform_bus, "sh_mobile_sdhi", 1, + platform_device_register_resndata(&platform_bus.dev, "sh_mobile_sdhi", 1, sdhi1_resources, ARRAY_SIZE(sdhi1_resources), &sdhi1_pdata, sizeof(sdhi1_pdata)); - platform_device_register_data(&platform_bus, "gpio-keys", -1, + platform_device_register_data(&platform_bus.dev, "gpio-keys", -1, &ape6evm_keys_pdata, sizeof(ape6evm_keys_pdata)); - platform_device_register_data(&platform_bus, "leds-gpio", -1, + platform_device_register_data(&platform_bus.dev, "leds-gpio", -1, &ape6evm_leds_pdata, sizeof(ape6evm_leds_pdata)); } diff --git a/arch/arm/mach-shmobile/board-bockw.c b/arch/arm/mach-shmobile/board-bockw.c index f444be2..07b9d2f 100644 --- a/arch/arm/mach-shmobile/board-bockw.c +++ b/arch/arm/mach-shmobile/board-bockw.c @@ -177,7 +177,7 @@ static struct renesas_usbhs_platform_info usbhs_info __initdata = { #define USB1_DEVICE "renesas_usbhs" #define ADD_USB_FUNC_DEVICE_IF_POSSIBLE() \ platform_device_register_resndata( \ - &platform_bus, "renesas_usbhs", -1, \ + &platform_bus.dev, "renesas_usbhs", -1, \ usbhsf_resources, \ ARRAY_SIZE(usbhsf_resources), \ &usbhs_info, sizeof(struct renesas_usbhs_platform_info)) @@ -236,7 +236,7 @@ static struct sh_eth_plat_data ether_platform_data __initdata = { }; static struct platform_device_info ether_info __initdata = { - .parent = &platform_bus, + .parent = &platform_bus.dev, .name = "r8a777x-ether", .id = -1, .res = ether_resources, @@ -322,7 +322,7 @@ static struct resource vin##idx##_resources[] __initdata = { \ }; \ \ static struct platform_device_info vin##idx##_info __initdata = { \ - .parent = &platform_bus, \ + .parent = &platform_bus.dev, \ .name = "r8a7778-vin", \ .id = idx, \ .res = vin##idx##_resources, \ @@ -621,10 +621,10 @@ static void __init bockw_init(void) /* VIN1 has a pin conflict with Ether */ if (!IS_ENABLED(CONFIG_SH_ETH)) platform_device_register_full(&vin1_info); - platform_device_register_data(&platform_bus, "soc-camera-pdrv", 0, + platform_device_register_data(&platform_bus.dev, "soc-camera-pdrv", 0, &iclink0_ml86v7667, sizeof(iclink0_ml86v7667)); - platform_device_register_data(&platform_bus, "soc-camera-pdrv", 1, + platform_device_register_data(&platform_bus.dev, "soc-camera-pdrv", 1, &iclink1_ml86v7667, sizeof(iclink1_ml86v7667)); @@ -637,12 +637,12 @@ static void __init bockw_init(void) r8a7778_pinmux_init(); platform_device_register_resndata( - &platform_bus, "sh_mmcif", -1, + &platform_bus.dev, "sh_mmcif", -1, mmc_resources, ARRAY_SIZE(mmc_resources), &sh_mmcif_plat, sizeof(struct sh_mmcif_plat_data)); platform_device_register_resndata( - &platform_bus, "rcar_usb_phy", -1, + &platform_bus.dev, "rcar_usb_phy", -1, usb_phy_resources, ARRAY_SIZE(usb_phy_resources), &usb_phy_platform_data, @@ -668,7 +668,7 @@ static void __init bockw_init(void) iowrite16(val, fpga + IRQ0MR); platform_device_register_resndata( - &platform_bus, "smsc911x", -1, + &platform_bus.dev, "smsc911x", -1, smsc911x_resources, ARRAY_SIZE(smsc911x_resources), &smsc911x_data, sizeof(smsc911x_data)); } @@ -685,7 +685,7 @@ static void __init bockw_init(void) iounmap(base); platform_device_register_resndata( - &platform_bus, "sh_mobile_sdhi", 0, + &platform_bus.dev, "sh_mobile_sdhi", 0, sdhi0_resources, ARRAY_SIZE(sdhi0_resources), &sdhi0_info, sizeof(struct sh_mobile_sdhi_info)); } @@ -700,7 +700,7 @@ static void __init bockw_init(void) "ak4554-adc-dac", 1, NULL, 0); pdev = platform_device_register_resndata( - &platform_bus, "rcar_sound", -1, + &platform_bus.dev, "rcar_sound", -1, rsnd_resources, ARRAY_SIZE(rsnd_resources), &rsnd_info, sizeof(rsnd_info)); @@ -710,7 +710,7 @@ static void __init bockw_init(void) for (i = 0; i < ARRAY_SIZE(rsnd_card_info); i++) { struct platform_device_info cardinfo = { - .parent = &platform_bus, + .parent = &platform_bus.dev, .name = "asoc-simple-card", .id = i, .data = &rsnd_card_info[i], diff --git a/arch/arm/mach-shmobile/board-genmai.c b/arch/arm/mach-shmobile/board-genmai.c index c94201e..cec50d4 100644 --- a/arch/arm/mach-shmobile/board-genmai.c +++ b/arch/arm/mach-shmobile/board-genmai.c @@ -46,7 +46,7 @@ static const struct resource ether_resources[] __initconst = { }; static const struct platform_device_info ether_info __initconst = { - .parent = &platform_bus, + .parent = &platform_bus.dev, .name = "r7s72100-ether", .id = -1, .res = ether_resources, @@ -76,7 +76,7 @@ static const struct rspi_plat_data rspi_pdata __initconst = { }; #define r7s72100_register_rspi(idx) \ - platform_device_register_resndata(&platform_bus, "rspi-rz", idx, \ + platform_device_register_resndata(&platform_bus.dev, "rspi-rz", idx, \ rspi##idx##_resources, \ ARRAY_SIZE(rspi##idx##_resources), \ &rspi_pdata, sizeof(rspi_pdata)) @@ -118,7 +118,7 @@ R7S72100_SCIF(6, 0xe800a000, gic_iid(245)); R7S72100_SCIF(7, 0xe800a800, gic_iid(249)); #define r7s72100_register_scif(index) \ - platform_device_register_resndata(&platform_bus, "sh-sci", index, \ + platform_device_register_resndata(&platform_bus.dev, "sh-sci", index, \ scif##index##_resources, \ ARRAY_SIZE(scif##index##_resources), \ &scif##index##_platform_data, \ diff --git a/arch/arm/mach-shmobile/board-koelsch.c b/arch/arm/mach-shmobile/board-koelsch.c index c6c6889..2341edd 100644 --- a/arch/arm/mach-shmobile/board-koelsch.c +++ b/arch/arm/mach-shmobile/board-koelsch.c @@ -118,7 +118,7 @@ static const struct resource ether_resources[] __initconst = { }; static const struct platform_device_info ether_info __initconst = { - .parent = &platform_bus, + .parent = &platform_bus.dev, .name = "r8a7791-ether", .id = -1, .res = ether_resources, @@ -230,7 +230,7 @@ static const struct resource sata0_resources[] __initconst = { }; static const struct platform_device_info sata0_info __initconst = { - .parent = &platform_bus, + .parent = &platform_bus.dev, .name = "sata-r8a7791", .id = 0, .res = sata0_resources, @@ -439,13 +439,13 @@ static void __init koelsch_add_standard_devices(void) r8a7791_pinmux_init(); r8a7791_add_standard_devices(); platform_device_register_full(ðer_info); - platform_device_register_data(&platform_bus, "leds-gpio", -1, + platform_device_register_data(&platform_bus.dev, "leds-gpio", -1, &koelsch_leds_pdata, sizeof(koelsch_leds_pdata)); - platform_device_register_data(&platform_bus, "gpio-keys", -1, + platform_device_register_data(&platform_bus.dev, "gpio-keys", -1, &koelsch_keys_pdata, sizeof(koelsch_keys_pdata)); - platform_device_register_resndata(&platform_bus, "qspi", 0, + platform_device_register_resndata(&platform_bus.dev, "qspi", 0, qspi_resources, ARRAY_SIZE(qspi_resources), &qspi_pdata, sizeof(qspi_pdata)); @@ -460,28 +460,28 @@ static void __init koelsch_add_standard_devices(void) koelsch_add_i2c(4); koelsch_add_i2c(5); - platform_device_register_data(&platform_bus, "reg-fixed-voltage", 0, + platform_device_register_data(&platform_bus.dev, "reg-fixed-voltage", 0, &vcc_sdhi0_info, sizeof(struct fixed_voltage_config)); - platform_device_register_data(&platform_bus, "reg-fixed-voltage", 1, + platform_device_register_data(&platform_bus.dev, "reg-fixed-voltage", 1, &vcc_sdhi1_info, sizeof(struct fixed_voltage_config)); - platform_device_register_data(&platform_bus, "reg-fixed-voltage", 2, + platform_device_register_data(&platform_bus.dev, "reg-fixed-voltage", 2, &vcc_sdhi2_info, sizeof(struct fixed_voltage_config)); - platform_device_register_data(&platform_bus, "gpio-regulator", 0, + platform_device_register_data(&platform_bus.dev, "gpio-regulator", 0, &vccq_sdhi0_info, sizeof(struct gpio_regulator_config)); - platform_device_register_data(&platform_bus, "gpio-regulator", 1, + platform_device_register_data(&platform_bus.dev, "gpio-regulator", 1, &vccq_sdhi1_info, sizeof(struct gpio_regulator_config)); - platform_device_register_data(&platform_bus, "gpio-regulator", 2, + platform_device_register_data(&platform_bus.dev, "gpio-regulator", 2, &vccq_sdhi2_info, sizeof(struct gpio_regulator_config)); - platform_device_register_resndata(&platform_bus, "sh_mobile_sdhi", 0, + platform_device_register_resndata(&platform_bus.dev, "sh_mobile_sdhi", 0, sdhi0_resources, ARRAY_SIZE(sdhi0_resources), &sdhi0_info, sizeof(struct sh_mobile_sdhi_info)); - platform_device_register_resndata(&platform_bus, "sh_mobile_sdhi", 1, + platform_device_register_resndata(&platform_bus.dev, "sh_mobile_sdhi", 1, sdhi1_resources, ARRAY_SIZE(sdhi1_resources), &sdhi1_info, sizeof(struct sh_mobile_sdhi_info)); - platform_device_register_resndata(&platform_bus, "sh_mobile_sdhi", 2, + platform_device_register_resndata(&platform_bus.dev, "sh_mobile_sdhi", 2, sdhi2_resources, ARRAY_SIZE(sdhi2_resources), &sdhi2_info, sizeof(struct sh_mobile_sdhi_info)); diff --git a/arch/arm/mach-shmobile/board-lager.c b/arch/arm/mach-shmobile/board-lager.c index f8b1e05..ec3ba5f 100644 --- a/arch/arm/mach-shmobile/board-lager.c +++ b/arch/arm/mach-shmobile/board-lager.c @@ -277,7 +277,7 @@ static const struct resource ether_resources[] __initconst = { }; static const struct platform_device_info ether_info __initconst = { - .parent = &platform_bus, + .parent = &platform_bus.dev, .name = "r8a7790-ether", .id = -1, .res = ether_resources, @@ -354,7 +354,7 @@ static void __init lager_add_vin_device(unsigned idx, struct rcar_vin_platform_data *pdata) { struct platform_device_info vin_info = { - .parent = &platform_bus, + .parent = &platform_bus.dev, .name = "r8a7790-vin", .id = idx, .res = &vin_resources[idx * 2], @@ -391,7 +391,7 @@ LAGER_CAMERA(1, "adv7180", 0x20, NULL, RCAR_VIN_BT656); static void __init lager_add_camera1_device(void) { - platform_device_register_data(&platform_bus, "soc-camera-pdrv", 1, + platform_device_register_data(&platform_bus.dev, "soc-camera-pdrv", 1, &cam1_link, sizeof(cam1_link)); lager_add_vin_device(1, &vin1_pdata); } @@ -403,7 +403,7 @@ static const struct resource sata1_resources[] __initconst = { }; static const struct platform_device_info sata1_info __initconst = { - .parent = &platform_bus, + .parent = &platform_bus.dev, .name = "sata-r8a7790", .id = 1, .res = sata1_resources, @@ -533,7 +533,7 @@ static struct usbhs_private usbhs_priv __initdata = { static void __init lager_register_usbhs(void) { usb_bind_phy("renesas_usbhs", 0, "usb_phy_rcar_gen2"); - platform_device_register_resndata(&platform_bus, + platform_device_register_resndata(&platform_bus.dev, "renesas_usbhs", -1, usbhs_resources, ARRAY_SIZE(usbhs_resources), @@ -608,7 +608,7 @@ static struct asoc_simple_card_info rsnd_card_info = { static void __init lager_add_rsnd_device(void) { struct platform_device_info cardinfo = { - .parent = &platform_bus, + .parent = &platform_bus.dev, .name = "asoc-simple-card", .id = -1, .data = &rsnd_card_info, @@ -620,7 +620,7 @@ static void __init lager_add_rsnd_device(void) ARRAY_SIZE(i2c2_devices)); platform_device_register_resndata( - &platform_bus, "rcar_sound", -1, + &platform_bus.dev, "rcar_sound", -1, rsnd_resources, ARRAY_SIZE(rsnd_resources), &rsnd_info, sizeof(rsnd_info)); @@ -663,7 +663,7 @@ static const struct resource pci1_resources[] __initconst = { }; static const struct platform_device_info pci1_info __initconst = { - .parent = &platform_bus, + .parent = &platform_bus.dev, .name = "pci-rcar-gen2", .id = 1, .res = pci1_resources, @@ -684,7 +684,7 @@ static const struct resource pci2_resources[] __initconst = { }; static const struct platform_device_info pci2_info __initconst = { - .parent = &platform_bus, + .parent = &platform_bus.dev, .name = "pci-rcar-gen2", .id = 2, .res = pci2_resources, @@ -795,16 +795,16 @@ static void __init lager_add_standard_devices(void) r8a7790_pinmux_init(); r8a7790_add_standard_devices(); - platform_device_register_data(&platform_bus, "leds-gpio", -1, + platform_device_register_data(&platform_bus.dev, "leds-gpio", -1, &lager_leds_pdata, sizeof(lager_leds_pdata)); - platform_device_register_data(&platform_bus, "gpio-keys", -1, + platform_device_register_data(&platform_bus.dev, "gpio-keys", -1, &lager_keys_pdata, sizeof(lager_keys_pdata)); regulator_register_always_on(fixed_regulator_idx++, "fixed-3.3V", fixed3v3_power_consumers, ARRAY_SIZE(fixed3v3_power_consumers), 3300000); - platform_device_register_resndata(&platform_bus, "sh_mmcif", 1, + platform_device_register_resndata(&platform_bus.dev, "sh_mmcif", 1, mmcif1_resources, ARRAY_SIZE(mmcif1_resources), &mmcif1_pdata, sizeof(mmcif1_pdata)); @@ -812,27 +812,27 @@ static void __init lager_add_standard_devices(void) lager_add_du_device(); - platform_device_register_resndata(&platform_bus, "qspi", 0, + platform_device_register_resndata(&platform_bus.dev, "qspi", 0, qspi_resources, ARRAY_SIZE(qspi_resources), &qspi_pdata, sizeof(qspi_pdata)); spi_register_board_info(spi_info, ARRAY_SIZE(spi_info)); - platform_device_register_data(&platform_bus, "reg-fixed-voltage", fixed_regulator_idx++, + platform_device_register_data(&platform_bus.dev, "reg-fixed-voltage", fixed_regulator_idx++, &vcc_sdhi0_info, sizeof(struct fixed_voltage_config)); - platform_device_register_data(&platform_bus, "reg-fixed-voltage", fixed_regulator_idx++, + platform_device_register_data(&platform_bus.dev, "reg-fixed-voltage", fixed_regulator_idx++, &vcc_sdhi2_info, sizeof(struct fixed_voltage_config)); - platform_device_register_data(&platform_bus, "gpio-regulator", gpio_regulator_idx++, + platform_device_register_data(&platform_bus.dev, "gpio-regulator", gpio_regulator_idx++, &vccq_sdhi0_info, sizeof(struct gpio_regulator_config)); - platform_device_register_data(&platform_bus, "gpio-regulator", gpio_regulator_idx++, + platform_device_register_data(&platform_bus.dev, "gpio-regulator", gpio_regulator_idx++, &vccq_sdhi2_info, sizeof(struct gpio_regulator_config)); lager_add_camera1_device(); platform_device_register_full(&sata1_info); - platform_device_register_resndata(&platform_bus, "usb_phy_rcar_gen2", + platform_device_register_resndata(&platform_bus.dev, "usb_phy_rcar_gen2", -1, usbhs_phy_resources, ARRAY_SIZE(usbhs_phy_resources), &usbhs_phy_pdata, @@ -843,10 +843,10 @@ static void __init lager_add_standard_devices(void) lager_add_rsnd_device(); - platform_device_register_resndata(&platform_bus, "sh_mobile_sdhi", 0, + platform_device_register_resndata(&platform_bus.dev, "sh_mobile_sdhi", 0, sdhi0_resources, ARRAY_SIZE(sdhi0_resources), &sdhi0_info, sizeof(struct sh_mobile_sdhi_info)); - platform_device_register_resndata(&platform_bus, "sh_mobile_sdhi", 2, + platform_device_register_resndata(&platform_bus.dev, "sh_mobile_sdhi", 2, sdhi2_resources, ARRAY_SIZE(sdhi2_resources), &sdhi2_info, sizeof(struct sh_mobile_sdhi_info)); } diff --git a/arch/arm/mach-shmobile/board-marzen.c b/arch/arm/mach-shmobile/board-marzen.c index d832a44..e374ce8 100644 --- a/arch/arm/mach-shmobile/board-marzen.c +++ b/arch/arm/mach-shmobile/board-marzen.c @@ -272,7 +272,7 @@ static struct resource vin##idx##_resources[] __initdata = { \ }; \ \ static struct platform_device_info vin##idx##_info __initdata = { \ - .parent = &platform_bus, \ + .parent = &platform_bus.dev, \ .name = "r8a7779-vin", \ .id = idx, \ .res = vin##idx##_resources, \ diff --git a/arch/arm/mach-shmobile/setup-r7s72100.c b/arch/arm/mach-shmobile/setup-r7s72100.c index 412e179..bb52e06 100644 --- a/arch/arm/mach-shmobile/setup-r7s72100.c +++ b/arch/arm/mach-shmobile/setup-r7s72100.c @@ -33,7 +33,7 @@ static struct resource mtu2_resources[] __initdata = { }; #define r7s72100_register_mtu2() \ - platform_device_register_resndata(&platform_bus, "sh-mtu2", \ + platform_device_register_resndata(&platform_bus.dev, "sh-mtu2", \ -1, mtu2_resources, \ ARRAY_SIZE(mtu2_resources), \ NULL, 0) diff --git a/arch/arm/mach-shmobile/setup-r8a73a4.c b/arch/arm/mach-shmobile/setup-r8a73a4.c index 9333770..1a3bb18 100644 --- a/arch/arm/mach-shmobile/setup-r8a73a4.c +++ b/arch/arm/mach-shmobile/setup-r8a73a4.c @@ -68,7 +68,7 @@ R8A73A4_SCIFB(4, 0xe6ce0000, gic_spi(150)); /* SCIFB2 */ R8A73A4_SCIFB(5, 0xe6cf0000, gic_spi(151)); /* SCIFB3 */ #define r8a73a4_register_scif(index) \ - platform_device_register_resndata(&platform_bus, "sh-sci", index, \ + platform_device_register_resndata(&platform_bus.dev, "sh-sci", index, \ scif##index##_resources, \ ARRAY_SIZE(scif##index##_resources), \ &scif##index##_platform_data, \ @@ -149,7 +149,7 @@ static const struct resource irqc1_resources[] = { }; #define r8a73a4_register_irqc(idx) \ - platform_device_register_resndata(&platform_bus, "renesas_irqc", \ + platform_device_register_resndata(&platform_bus.dev, "renesas_irqc", \ idx, irqc##idx##_resources, \ ARRAY_SIZE(irqc##idx##_resources), \ &irqc##idx##_data, \ @@ -179,7 +179,7 @@ static struct resource cmt1_resources[] = { }; #define r8a7790_register_cmt(idx) \ - platform_device_register_resndata(&platform_bus, "sh-cmt-48-gen2", \ + platform_device_register_resndata(&platform_bus.dev, "sh-cmt-48-gen2", \ idx, cmt##idx##_resources, \ ARRAY_SIZE(cmt##idx##_resources), \ &cmt##idx##_platform_data, \ @@ -280,7 +280,7 @@ static struct resource dma_resources[] = { }; #define r8a73a4_register_dmac() \ - platform_device_register_resndata(&platform_bus, "sh-dma-engine", 0, \ + platform_device_register_resndata(&platform_bus.dev, "sh-dma-engine", 0,\ dma_resources, ARRAY_SIZE(dma_resources), \ &dma_pdata, sizeof(dma_pdata)) diff --git a/arch/arm/mach-shmobile/setup-r8a7778.c b/arch/arm/mach-shmobile/setup-r8a7778.c index d311ef9..d497cad 100644 --- a/arch/arm/mach-shmobile/setup-r8a7778.c +++ b/arch/arm/mach-shmobile/setup-r8a7778.c @@ -64,7 +64,7 @@ R8A7778_SCIF(4, 0xffe44000, gic_iid(0x6a)); R8A7778_SCIF(5, 0xffe45000, gic_iid(0x6b)); #define r8a7778_register_scif(index) \ - platform_device_register_resndata(&platform_bus, "sh-sci", index, \ + platform_device_register_resndata(&platform_bus.dev, "sh-sci", index, \ scif##index##_resources, \ ARRAY_SIZE(scif##index##_resources), \ &scif##index##_platform_data, \ @@ -84,7 +84,7 @@ static struct resource sh_tmu0_resources[] = { #define r8a7778_register_tmu(idx) \ platform_device_register_resndata( \ - &platform_bus, "sh-tmu", idx, \ + &platform_bus.dev, "sh-tmu", idx, \ sh_tmu##idx##_resources, \ ARRAY_SIZE(sh_tmu##idx##_resources), \ &sh_tmu##idx##_platform_data, \ @@ -173,7 +173,7 @@ static struct resource ohci_resources[] __initdata = { #define USB_PLATFORM_INFO(hci) \ static struct platform_device_info hci##_info __initdata = { \ - .parent = &platform_bus, \ + .parent = &platform_bus.dev, \ .name = #hci "-platform", \ .id = -1, \ .res = hci##_resources, \ @@ -212,7 +212,7 @@ R8A7778_GPIO(4); #define r8a7778_register_gpio(idx) \ platform_device_register_resndata( \ - &platform_bus, "gpio_rcar", idx, \ + &platform_bus.dev, "gpio_rcar", idx, \ r8a7778_gpio##idx##_resources, \ ARRAY_SIZE(r8a7778_gpio##idx##_resources), \ &r8a7778_gpio##idx##_platform_data, \ @@ -496,8 +496,8 @@ static struct resource hpb_dmae_resources[] __initdata = { static void __init r8a7778_register_hpb_dmae(void) { - platform_device_register_resndata(&platform_bus, "hpb-dma-engine", -1, - hpb_dmae_resources, + platform_device_register_resndata(&platform_bus.dev, "hpb-dma-engine", + -1, hpb_dmae_resources, ARRAY_SIZE(hpb_dmae_resources), &dma_platform_data, sizeof(dma_platform_data)); @@ -565,7 +565,7 @@ void __init r8a7778_init_irq_extpin(int irlm) r8a7778_init_irq_extpin_dt(irlm); if (irlm) platform_device_register_resndata( - &platform_bus, "renesas_intc_irqpin", -1, + &platform_bus.dev, "renesas_intc_irqpin", -1, irqpin_resources, ARRAY_SIZE(irqpin_resources), &irqpin_platform_data, sizeof(irqpin_platform_data)); } diff --git a/arch/arm/mach-shmobile/setup-r8a7779.c b/arch/arm/mach-shmobile/setup-r8a7779.c index aba4ed6..ca9111f 100644 --- a/arch/arm/mach-shmobile/setup-r8a7779.c +++ b/arch/arm/mach-shmobile/setup-r8a7779.c @@ -123,7 +123,7 @@ void __init r8a7779_init_irq_extpin(int irlm) r8a7779_init_irq_extpin_dt(irlm); if (irlm) platform_device_register_resndata( - &platform_bus, "renesas_intc_irqpin", -1, + &platform_bus.dev, "renesas_intc_irqpin", -1, irqpin0_resources, ARRAY_SIZE(irqpin0_resources), &irqpin0_platform_data, sizeof(irqpin0_platform_data)); } @@ -632,8 +632,8 @@ static struct resource hpb_dmae_resources[] __initdata = { static void __init r8a7779_register_hpb_dmae(void) { - platform_device_register_resndata(&platform_bus, "hpb-dma-engine", -1, - hpb_dmae_resources, + platform_device_register_resndata(&platform_bus.dev, "hpb-dma-engine", + -1, hpb_dmae_resources, ARRAY_SIZE(hpb_dmae_resources), &dma_platform_data, sizeof(dma_platform_data)); diff --git a/arch/arm/mach-shmobile/setup-r8a7790.c b/arch/arm/mach-shmobile/setup-r8a7790.c index 6bd08b1..4bcb2f4 100644 --- a/arch/arm/mach-shmobile/setup-r8a7790.c +++ b/arch/arm/mach-shmobile/setup-r8a7790.c @@ -113,7 +113,7 @@ static struct resource r8a7790_audio_dmac_resources[] = { #define r8a7790_register_audio_dmac(id) \ platform_device_register_resndata( \ - &platform_bus, "sh-dma-engine", id, \ + &platform_bus.dev, "sh-dma-engine", id, \ &r8a7790_audio_dmac_resources[id * 3], 3, \ &r8a7790_audio_dmac_platform_data, \ sizeof(r8a7790_audio_dmac_platform_data)) @@ -149,7 +149,7 @@ R8A7790_GPIO(4); R8A7790_GPIO(5); #define r8a7790_register_gpio(idx) \ - platform_device_register_resndata(&platform_bus, "gpio_rcar", idx, \ + platform_device_register_resndata(&platform_bus.dev, "gpio_rcar", idx, \ r8a7790_gpio##idx##_resources, \ ARRAY_SIZE(r8a7790_gpio##idx##_resources), \ &r8a7790_gpio##idx##_platform_data, \ @@ -227,7 +227,7 @@ R8A7790_HSCIF(8, 0xe62c0000, gic_spi(154)); /* HSCIF0 */ R8A7790_HSCIF(9, 0xe62c8000, gic_spi(155)); /* HSCIF1 */ #define r8a7790_register_scif(index) \ - platform_device_register_resndata(&platform_bus, "sh-sci", index, \ + platform_device_register_resndata(&platform_bus.dev, "sh-sci", index, \ scif##index##_resources, \ ARRAY_SIZE(scif##index##_resources), \ &scif##index##_platform_data, \ @@ -246,7 +246,7 @@ static const struct resource irqc0_resources[] __initconst = { }; #define r8a7790_register_irqc(idx) \ - platform_device_register_resndata(&platform_bus, "renesas_irqc", \ + platform_device_register_resndata(&platform_bus.dev, "renesas_irqc", \ idx, irqc##idx##_resources, \ ARRAY_SIZE(irqc##idx##_resources), \ &irqc##idx##_data, \ @@ -273,7 +273,7 @@ static struct resource cmt0_resources[] = { }; #define r8a7790_register_cmt(idx) \ - platform_device_register_resndata(&platform_bus, "sh-cmt-48-gen2", \ + platform_device_register_resndata(&platform_bus.dev, "sh-cmt-48-gen2", \ idx, cmt##idx##_resources, \ ARRAY_SIZE(cmt##idx##_resources), \ &cmt##idx##_platform_data, \ diff --git a/arch/arm/mach-shmobile/setup-r8a7791.c b/arch/arm/mach-shmobile/setup-r8a7791.c index 04a96dd..bd5cef2 100644 --- a/arch/arm/mach-shmobile/setup-r8a7791.c +++ b/arch/arm/mach-shmobile/setup-r8a7791.c @@ -65,7 +65,7 @@ R8A7791_GPIO(6, 0xe6055400, 32); R8A7791_GPIO(7, 0xe6055800, 26); #define r8a7791_register_gpio(idx) \ - platform_device_register_resndata(&platform_bus, "gpio_rcar", idx, \ + platform_device_register_resndata(&platform_bus.dev, "gpio_rcar", idx, \ r8a7791_gpio##idx##_resources, \ ARRAY_SIZE(r8a7791_gpio##idx##_resources), \ &r8a7791_gpio##idx##_platform_data, \ @@ -122,7 +122,7 @@ R8A7791_SCIFA(13, 0xe6c78000, gic_spi(30)); /* SCIFA4 */ R8A7791_SCIFA(14, 0xe6c80000, gic_spi(31)); /* SCIFA5 */ #define r8a7791_register_scif(index) \ - platform_device_register_resndata(&platform_bus, "sh-sci", index, \ + platform_device_register_resndata(&platform_bus.dev, "sh-sci", index, \ scif##index##_resources, \ ARRAY_SIZE(scif##index##_resources), \ &scif##index##_platform_data, \ @@ -138,7 +138,7 @@ static struct resource cmt0_resources[] = { }; #define r8a7791_register_cmt(idx) \ - platform_device_register_resndata(&platform_bus, "sh-cmt-48-gen2", \ + platform_device_register_resndata(&platform_bus.dev, "sh-cmt-48-gen2", \ idx, cmt##idx##_resources, \ ARRAY_SIZE(cmt##idx##_resources), \ &cmt##idx##_platform_data, \ @@ -163,7 +163,7 @@ static struct resource irqc0_resources[] = { }; #define r8a7791_register_irqc(idx) \ - platform_device_register_resndata(&platform_bus, "renesas_irqc", \ + platform_device_register_resndata(&platform_bus.dev, "renesas_irqc", \ idx, irqc##idx##_resources, \ ARRAY_SIZE(irqc##idx##_resources), \ &irqc##idx##_data, \ diff --git a/arch/unicore32/kernel/puv3-core.c b/arch/unicore32/kernel/puv3-core.c index 254adee..28d1387 100644 --- a/arch/unicore32/kernel/puv3-core.c +++ b/arch/unicore32/kernel/puv3-core.c @@ -272,7 +272,7 @@ void __init puv3_core_init(void) platform_device_register_simple("PKUnity-v3-UART", 1, puv3_uart1_resources, ARRAY_SIZE(puv3_uart1_resources)); platform_device_register_simple("PKUnity-v3-AC97", -1, NULL, 0); - platform_device_register_resndata(&platform_bus, "musb_hdrc", -1, + platform_device_register_resndata(&platform_bus.dev, "musb_hdrc", -1, puv3_usb_resources, ARRAY_SIZE(puv3_usb_resources), &puv3_usb_plat, sizeof(puv3_usb_plat)); } diff --git a/arch/unicore32/kernel/puv3-nb0916.c b/arch/unicore32/kernel/puv3-nb0916.c index 0c6618e..4b1c462 100644 --- a/arch/unicore32/kernel/puv3-nb0916.c +++ b/arch/unicore32/kernel/puv3-nb0916.c @@ -112,13 +112,13 @@ int __init mach_nb0916_init(void) platform_device_register_simple("PKUnity-v3-I2C", -1, puv3_i2c_resources, ARRAY_SIZE(puv3_i2c_resources)); - platform_device_register_data(&platform_bus, "pwm-backlight", -1, + platform_device_register_data(&platform_bus.dev, "pwm-backlight", -1, &nb0916_backlight_data, sizeof(nb0916_backlight_data)); - platform_device_register_data(&platform_bus, "gpio-keys", -1, + platform_device_register_data(&platform_bus.dev, "gpio-keys", -1, &nb0916_gpio_button_data, sizeof(nb0916_gpio_button_data)); - platform_device_register_resndata(&platform_bus, "physmap-flash", -1, + platform_device_register_resndata(&platform_bus.dev, "physmap-flash", -1, &physmap_flash_resource, 1, &physmap_flash_data, sizeof(physmap_flash_data)); diff --git a/drivers/base/platform.c b/drivers/base/platform.c index eee48c4..f272603 100644 --- a/drivers/base/platform.c +++ b/drivers/base/platform.c @@ -30,8 +30,8 @@ /* For automatically allocated device IDs */ static DEFINE_IDA(platform_devid_ida); -struct device platform_bus = { - .init_name = "platform", +struct platform_device platform_bus = { + .name = "platform", }; EXPORT_SYMBOL_GPL(platform_bus); @@ -300,7 +300,7 @@ int platform_device_add(struct platform_device *pdev) return -EINVAL; if (!pdev->dev.parent) - pdev->dev.parent = &platform_bus; + pdev->dev.parent = &platform_bus.dev; pdev->dev.bus = &platform_bus_type; @@ -946,12 +946,18 @@ int __init platform_bus_init(void) early_platform_cleanup(); - error = device_register(&platform_bus); + dev_set_name(&platform_bus.dev, "%s", platform_bus.name); + error = device_register(&platform_bus.dev); if (error) return error; error = bus_register(&platform_bus_type); - if (error) - device_unregister(&platform_bus); + if (!error) { + platform_bus.dev.of_node = of_allnodes; + platform_bus.dev.bus = &platform_bus_type; + bus_add_device(&platform_bus.dev); + } else { + device_unregister(&platform_bus.dev); + } return error; } diff --git a/drivers/char/tile-srom.c b/drivers/char/tile-srom.c index bd37747..4e4b7a2 100644 --- a/drivers/char/tile-srom.c +++ b/drivers/char/tile-srom.c @@ -350,7 +350,7 @@ static int srom_setup_minor(struct srom_dev *srom, int index) SROM_PAGE_SIZE_OFF, sizeof(srom->page_size)) < 0) return -EIO; - dev = device_create(srom_class, &platform_bus, + dev = device_create(srom_class, &platform_bus.dev, MKDEV(srom_major, index), srom, "%d", index); return PTR_ERR_OR_ZERO(dev); } diff --git a/drivers/mmc/host/sdhci-pltfm.c b/drivers/mmc/host/sdhci-pltfm.c index 7e834fb..9a2b0d0 100644 --- a/drivers/mmc/host/sdhci-pltfm.c +++ b/drivers/mmc/host/sdhci-pltfm.c @@ -137,7 +137,7 @@ struct sdhci_host *sdhci_pltfm_init(struct platform_device *pdev, dev_err(&pdev->dev, "Invalid iomem size!\n"); /* Some PCI-based MFD need the parent here */ - if (pdev->dev.parent != &platform_bus && !np) + if (pdev->dev.parent != &platform_bus.dev && !np) host = sdhci_alloc_host(pdev->dev.parent, sizeof(struct sdhci_pltfm_host) + priv_size); else diff --git a/drivers/scsi/hosts.c b/drivers/scsi/hosts.c index 3cbb57a..c14c36f 100644 --- a/drivers/scsi/hosts.c +++ b/drivers/scsi/hosts.c @@ -218,7 +218,7 @@ int scsi_add_host_with_dma(struct Scsi_Host *shost, struct device *dev, goto fail; if (!shost->shost_gendev.parent) - shost->shost_gendev.parent = dev ? dev : &platform_bus; + shost->shost_gendev.parent = dev ? dev : &platform_bus.dev; if (!dma_dev) dma_dev = shost->shost_gendev.parent; diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h index 16f6654..a99032a 100644 --- a/include/linux/platform_device.h +++ b/include/linux/platform_device.h @@ -44,7 +44,7 @@ extern int platform_device_register(struct platform_device *); extern void platform_device_unregister(struct platform_device *); extern struct bus_type platform_bus_type; -extern struct device platform_bus; +extern struct platform_device platform_bus; extern void arch_setup_pdev_archdata(struct platform_device *); extern struct resource *platform_get_resource(struct platform_device *, -- 1.9.1 ^ permalink raw reply related [flat|nested] 48+ messages in thread
* [PATCH v2] platform: Make platform_bus device a platform device 2014-07-22 10:02 ` [PATCH v2] " Pawel Moll @ 2014-07-22 17:10 ` Greg Kroah-Hartman 2014-07-22 17:30 ` Pawel Moll 0 siblings, 1 reply; 48+ messages in thread From: Greg Kroah-Hartman @ 2014-07-22 17:10 UTC (permalink / raw) To: linux-arm-kernel On Tue, Jul 22, 2014 at 11:02:07AM +0100, Pawel Moll wrote: > ... describing the root of the device tree, so one can write > a platform driver initializing the platform. > > All references to platform_bus device have been fixed up, > although in most cases they could be simply removed or > replaced by NULL (platform devices with no parent are adopted > by main platform_bus device automagically). In looking at this some more, I think all of these should be made NULL, why are we exporting this symbol at all? I think we should remove all of these references, and just make platform_bus static, like all other busses are, no reason platform should be "special" here. It's "special" enough as it is :( thanks, greg k-h ^ permalink raw reply [flat|nested] 48+ messages in thread
* [PATCH v2] platform: Make platform_bus device a platform device 2014-07-22 17:10 ` Greg Kroah-Hartman @ 2014-07-22 17:30 ` Pawel Moll 2014-07-22 17:37 ` Greg Kroah-Hartman 0 siblings, 1 reply; 48+ messages in thread From: Pawel Moll @ 2014-07-22 17:30 UTC (permalink / raw) To: linux-arm-kernel On Tue, 2014-07-22 at 18:10 +0100, Greg Kroah-Hartman wrote: > On Tue, Jul 22, 2014 at 11:02:07AM +0100, Pawel Moll wrote: > > ... describing the root of the device tree, so one can write > > a platform driver initializing the platform. > > > > All references to platform_bus device have been fixed up, > > although in most cases they could be simply removed or > > replaced by NULL (platform devices with no parent are adopted > > by main platform_bus device automagically). > > In looking at this some more, I think all of these should be made NULL, > why are we exporting this symbol at all? I think there are about 3 non-obvious uses of it, which would probably need looking into. All other ones that simply do of_platform_populate() or platform_device_register*() with platform_bus as a parent, which has exactly the same effect as it was NULL. I can imagine situations where one would want to walk the device hierarchy stopping at platform_bus, how I'm not sure how "legitimate" that would be. I'll post v3 with NULLs where I think it is enough so we can see the other cases. Pawel ^ permalink raw reply [flat|nested] 48+ messages in thread
* [PATCH v2] platform: Make platform_bus device a platform device 2014-07-22 17:30 ` Pawel Moll @ 2014-07-22 17:37 ` Greg Kroah-Hartman 2014-07-22 17:55 ` [PATCH v3] " Pawel Moll 0 siblings, 1 reply; 48+ messages in thread From: Greg Kroah-Hartman @ 2014-07-22 17:37 UTC (permalink / raw) To: linux-arm-kernel On Tue, Jul 22, 2014 at 06:30:06PM +0100, Pawel Moll wrote: > On Tue, 2014-07-22 at 18:10 +0100, Greg Kroah-Hartman wrote: > > On Tue, Jul 22, 2014 at 11:02:07AM +0100, Pawel Moll wrote: > > > ... describing the root of the device tree, so one can write > > > a platform driver initializing the platform. > > > > > > All references to platform_bus device have been fixed up, > > > although in most cases they could be simply removed or > > > replaced by NULL (platform devices with no parent are adopted > > > by main platform_bus device automagically). > > > > In looking at this some more, I think all of these should be made NULL, > > why are we exporting this symbol at all? > > I think there are about 3 non-obvious uses of it, which would probably > need looking into. All other ones that simply do of_platform_populate() > or platform_device_register*() with platform_bus as a parent, which has > exactly the same effect as it was NULL. > > I can imagine situations where one would want to walk the device > hierarchy stopping at platform_bus, how I'm not sure how "legitimate" > that would be. Not at all "legitimate", use the functions the kernel provides for you if you really wanted to do that instead of trying to do it yourself. > I'll post v3 with NULLs where I think it is enough so we can see the > other cases. Thanks, that would be great. greg k-h ^ permalink raw reply [flat|nested] 48+ messages in thread
* [PATCH v3] platform: Make platform_bus device a platform device 2014-07-22 17:37 ` Greg Kroah-Hartman @ 2014-07-22 17:55 ` Pawel Moll 2014-07-22 18:01 ` Pawel Moll ` (2 more replies) 0 siblings, 3 replies; 48+ messages in thread From: Pawel Moll @ 2014-07-22 17:55 UTC (permalink / raw) To: linux-arm-kernel ... describing the root of the device tree, so one can write a platform driver initializing the platform. There has been a lot of references to platform_bus device where it didn't make any sense, because simply using NULL as a parent will make the device be adopted by the top level anyway. Signed-off-by: Pawel Moll <pawel.moll@arm.com> --- Changes since v2: * replaced references to platform_bus.dev with NULL in places where it shouldn't make any difference Changes since v1: * rebased on top of v3.16-rc6 * fixed up all new explicit references to platform_bus, with majority in mach-shmobile; 99% of them seem completely useless and I was *very* tempted to replace them with NULL - all reasons for and against this are welcomed arch/arm/mach-bcm/board_bcm21664.c | 3 +-- arch/arm/mach-bcm/board_bcm281xx.c | 3 +-- arch/arm/mach-clps711x/board-edb7211.c | 6 +++--- arch/arm/mach-clps711x/board-p720t.c | 6 +++--- arch/arm/mach-imx/devices/devices.c | 4 ++-- arch/arm/mach-imx/mach-mx27ads.c | 2 +- arch/arm/mach-shmobile/board-ape6evm.c | 14 +++++++------- arch/arm/mach-shmobile/board-bockw.c | 19 ++++++++---------- arch/arm/mach-shmobile/board-genmai.c | 5 ++--- arch/arm/mach-shmobile/board-koelsch.c | 26 ++++++++++++------------- arch/arm/mach-shmobile/board-lager.c | 34 ++++++++++++++------------------- arch/arm/mach-shmobile/board-marzen.c | 1 - arch/arm/mach-shmobile/setup-r7s72100.c | 2 +- arch/arm/mach-shmobile/setup-r8a73a4.c | 8 ++++---- arch/arm/mach-shmobile/setup-r8a7778.c | 13 ++++++------- arch/arm/mach-shmobile/setup-r8a7779.c | 6 +++--- arch/arm/mach-shmobile/setup-r8a7790.c | 10 +++++----- arch/arm/mach-shmobile/setup-r8a7791.c | 8 ++++---- arch/unicore32/kernel/puv3-core.c | 2 +- arch/unicore32/kernel/puv3-nb0916.c | 6 +++--- drivers/base/platform.c | 18 +++++++++++------ drivers/char/tile-srom.c | 2 +- drivers/mmc/host/sdhci-pltfm.c | 2 +- drivers/scsi/hosts.c | 2 +- include/linux/platform_device.h | 2 +- 25 files changed, 97 insertions(+), 107 deletions(-) diff --git a/arch/arm/mach-bcm/board_bcm21664.c b/arch/arm/mach-bcm/board_bcm21664.c index f0521cc..82ad568 100644 --- a/arch/arm/mach-bcm/board_bcm21664.c +++ b/arch/arm/mach-bcm/board_bcm21664.c @@ -60,8 +60,7 @@ static void bcm21664_restart(enum reboot_mode mode, const char *cmd) static void __init bcm21664_init(void) { - of_platform_populate(NULL, of_default_bus_match_table, NULL, - &platform_bus); + of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL); kona_l2_cache_init(); } diff --git a/arch/arm/mach-bcm/board_bcm281xx.c b/arch/arm/mach-bcm/board_bcm281xx.c index 1ac59fc..2e367bd 100644 --- a/arch/arm/mach-bcm/board_bcm281xx.c +++ b/arch/arm/mach-bcm/board_bcm281xx.c @@ -58,8 +58,7 @@ static void bcm281xx_restart(enum reboot_mode mode, const char *cmd) static void __init bcm281xx_init(void) { - of_platform_populate(NULL, of_default_bus_match_table, NULL, - &platform_bus); + of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL); kona_l2_cache_init(); } diff --git a/arch/arm/mach-clps711x/board-edb7211.c b/arch/arm/mach-clps711x/board-edb7211.c index f9828f8..6144fb5 100644 --- a/arch/arm/mach-clps711x/board-edb7211.c +++ b/arch/arm/mach-clps711x/board-edb7211.c @@ -158,16 +158,16 @@ static void __init edb7211_init_late(void) gpio_request_array(edb7211_gpios, ARRAY_SIZE(edb7211_gpios)); platform_device_register(&edb7211_flash_pdev); - platform_device_register_data(&platform_bus, "platform-lcd", 0, + platform_device_register_data(NULL, "platform-lcd", 0, &edb7211_lcd_power_pdata, sizeof(edb7211_lcd_power_pdata)); - platform_device_register_data(&platform_bus, "generic-bl", 0, + platform_device_register_data(NULL, "generic-bl", 0, &edb7211_lcd_backlight_pdata, sizeof(edb7211_lcd_backlight_pdata)); platform_device_register_simple("video-clps711x", 0, NULL, 0); platform_device_register_simple("cs89x0", 0, edb7211_cs8900_resource, ARRAY_SIZE(edb7211_cs8900_resource)); - platform_device_register_data(&platform_bus, "i2c-gpio", 0, + platform_device_register_data(NULL, "i2c-gpio", 0, &edb7211_i2c_pdata, sizeof(edb7211_i2c_pdata)); } diff --git a/arch/arm/mach-clps711x/board-p720t.c b/arch/arm/mach-clps711x/board-p720t.c index 0cf0e51..96bcc76 100644 --- a/arch/arm/mach-clps711x/board-p720t.c +++ b/arch/arm/mach-clps711x/board-p720t.c @@ -348,14 +348,14 @@ static void __init p720t_init_late(void) { WARN_ON(gpio_request_array(p720t_gpios, ARRAY_SIZE(p720t_gpios))); - platform_device_register_data(&platform_bus, "platform-lcd", 0, + platform_device_register_data(NULL, "platform-lcd", 0, &p720t_lcd_power_pdata, sizeof(p720t_lcd_power_pdata)); - platform_device_register_data(&platform_bus, "generic-bl", 0, + platform_device_register_data(NULL, "generic-bl", 0, &p720t_lcd_backlight_pdata, sizeof(p720t_lcd_backlight_pdata)); platform_device_register_simple("video-clps711x", 0, NULL, 0); - platform_device_register_data(&platform_bus, "leds-gpio", 0, + platform_device_register_data(NULL, "leds-gpio", 0, &p720t_gpio_led_pdata, sizeof(p720t_gpio_led_pdata)); } diff --git a/arch/arm/mach-imx/devices/devices.c b/arch/arm/mach-imx/devices/devices.c index 1b4366a..48c3817 100644 --- a/arch/arm/mach-imx/devices/devices.c +++ b/arch/arm/mach-imx/devices/devices.c @@ -24,12 +24,12 @@ struct device mxc_aips_bus = { .init_name = "mxc_aips", - .parent = &platform_bus, + .parent = &platform_bus.dev, }; struct device mxc_ahb_bus = { .init_name = "mxc_ahb", - .parent = &platform_bus, + .parent = &platform_bus.dev, }; int __init mxc_device_init(void) diff --git a/arch/arm/mach-imx/mach-mx27ads.c b/arch/arm/mach-imx/mach-mx27ads.c index 2f834ce..eb1c347 100644 --- a/arch/arm/mach-imx/mach-mx27ads.c +++ b/arch/arm/mach-imx/mach-mx27ads.c @@ -245,7 +245,7 @@ static void __init mx27ads_regulator_init(void) vchip->set = vgpio_set; gpiochip_add(vchip); - platform_device_register_data(&platform_bus, "reg-fixed-voltage", + platform_device_register_data(NULL, "reg-fixed-voltage", PLATFORM_DEVID_AUTO, &mx27ads_lcd_regulator_pdata, sizeof(mx27ads_lcd_regulator_pdata)); diff --git a/arch/arm/mach-shmobile/board-ape6evm.c b/arch/arm/mach-shmobile/board-ape6evm.c index fe071a9..7ab99a4 100644 --- a/arch/arm/mach-shmobile/board-ape6evm.c +++ b/arch/arm/mach-shmobile/board-ape6evm.c @@ -248,29 +248,29 @@ static void __init ape6evm_add_standard_devices(void) regulator_register_fixed(0, dummy_supplies, ARRAY_SIZE(dummy_supplies)); - platform_device_register_resndata(&platform_bus, "smsc911x", -1, + platform_device_register_resndata(NULL, "smsc911x", -1, lan9220_res, ARRAY_SIZE(lan9220_res), &lan9220_data, sizeof(lan9220_data)); regulator_register_always_on(1, "MMC0 Vcc", vcc_mmc0_consumers, ARRAY_SIZE(vcc_mmc0_consumers), 2800000); - platform_device_register_resndata(&platform_bus, "sh_mmcif", 0, + platform_device_register_resndata(NULL, "sh_mmcif", 0, mmcif0_resources, ARRAY_SIZE(mmcif0_resources), &mmcif0_pdata, sizeof(mmcif0_pdata)); - platform_device_register_data(&platform_bus, "reg-fixed-voltage", 2, + platform_device_register_data(NULL, "reg-fixed-voltage", 2, &vcc_sdhi0_info, sizeof(vcc_sdhi0_info)); - platform_device_register_resndata(&platform_bus, "sh_mobile_sdhi", 0, + platform_device_register_resndata(NULL, "sh_mobile_sdhi", 0, sdhi0_resources, ARRAY_SIZE(sdhi0_resources), &sdhi0_pdata, sizeof(sdhi0_pdata)); regulator_register_always_on(3, "SDHI1 Vcc", vcc_sdhi1_consumers, ARRAY_SIZE(vcc_sdhi1_consumers), 3300000); - platform_device_register_resndata(&platform_bus, "sh_mobile_sdhi", 1, + platform_device_register_resndata(NULL, "sh_mobile_sdhi", 1, sdhi1_resources, ARRAY_SIZE(sdhi1_resources), &sdhi1_pdata, sizeof(sdhi1_pdata)); - platform_device_register_data(&platform_bus, "gpio-keys", -1, + platform_device_register_data(NULL, "gpio-keys", -1, &ape6evm_keys_pdata, sizeof(ape6evm_keys_pdata)); - platform_device_register_data(&platform_bus, "leds-gpio", -1, + platform_device_register_data(NULL, "leds-gpio", -1, &ape6evm_leds_pdata, sizeof(ape6evm_leds_pdata)); } diff --git a/arch/arm/mach-shmobile/board-bockw.c b/arch/arm/mach-shmobile/board-bockw.c index f444be2..3ec82a4 100644 --- a/arch/arm/mach-shmobile/board-bockw.c +++ b/arch/arm/mach-shmobile/board-bockw.c @@ -177,7 +177,7 @@ static struct renesas_usbhs_platform_info usbhs_info __initdata = { #define USB1_DEVICE "renesas_usbhs" #define ADD_USB_FUNC_DEVICE_IF_POSSIBLE() \ platform_device_register_resndata( \ - &platform_bus, "renesas_usbhs", -1, \ + NULL, "renesas_usbhs", -1, \ usbhsf_resources, \ ARRAY_SIZE(usbhsf_resources), \ &usbhs_info, sizeof(struct renesas_usbhs_platform_info)) @@ -236,7 +236,6 @@ static struct sh_eth_plat_data ether_platform_data __initdata = { }; static struct platform_device_info ether_info __initdata = { - .parent = &platform_bus, .name = "r8a777x-ether", .id = -1, .res = ether_resources, @@ -322,7 +321,6 @@ static struct resource vin##idx##_resources[] __initdata = { \ }; \ \ static struct platform_device_info vin##idx##_info __initdata = { \ - .parent = &platform_bus, \ .name = "r8a7778-vin", \ .id = idx, \ .res = vin##idx##_resources, \ @@ -621,10 +619,10 @@ static void __init bockw_init(void) /* VIN1 has a pin conflict with Ether */ if (!IS_ENABLED(CONFIG_SH_ETH)) platform_device_register_full(&vin1_info); - platform_device_register_data(&platform_bus, "soc-camera-pdrv", 0, + platform_device_register_data(NULL, "soc-camera-pdrv", 0, &iclink0_ml86v7667, sizeof(iclink0_ml86v7667)); - platform_device_register_data(&platform_bus, "soc-camera-pdrv", 1, + platform_device_register_data(NULL, "soc-camera-pdrv", 1, &iclink1_ml86v7667, sizeof(iclink1_ml86v7667)); @@ -637,12 +635,12 @@ static void __init bockw_init(void) r8a7778_pinmux_init(); platform_device_register_resndata( - &platform_bus, "sh_mmcif", -1, + NULL, "sh_mmcif", -1, mmc_resources, ARRAY_SIZE(mmc_resources), &sh_mmcif_plat, sizeof(struct sh_mmcif_plat_data)); platform_device_register_resndata( - &platform_bus, "rcar_usb_phy", -1, + NULL, "rcar_usb_phy", -1, usb_phy_resources, ARRAY_SIZE(usb_phy_resources), &usb_phy_platform_data, @@ -668,7 +666,7 @@ static void __init bockw_init(void) iowrite16(val, fpga + IRQ0MR); platform_device_register_resndata( - &platform_bus, "smsc911x", -1, + NULL, "smsc911x", -1, smsc911x_resources, ARRAY_SIZE(smsc911x_resources), &smsc911x_data, sizeof(smsc911x_data)); } @@ -685,7 +683,7 @@ static void __init bockw_init(void) iounmap(base); platform_device_register_resndata( - &platform_bus, "sh_mobile_sdhi", 0, + NULL, "sh_mobile_sdhi", 0, sdhi0_resources, ARRAY_SIZE(sdhi0_resources), &sdhi0_info, sizeof(struct sh_mobile_sdhi_info)); } @@ -700,7 +698,7 @@ static void __init bockw_init(void) "ak4554-adc-dac", 1, NULL, 0); pdev = platform_device_register_resndata( - &platform_bus, "rcar_sound", -1, + NULL, "rcar_sound", -1, rsnd_resources, ARRAY_SIZE(rsnd_resources), &rsnd_info, sizeof(rsnd_info)); @@ -710,7 +708,6 @@ static void __init bockw_init(void) for (i = 0; i < ARRAY_SIZE(rsnd_card_info); i++) { struct platform_device_info cardinfo = { - .parent = &platform_bus, .name = "asoc-simple-card", .id = i, .data = &rsnd_card_info[i], diff --git a/arch/arm/mach-shmobile/board-genmai.c b/arch/arm/mach-shmobile/board-genmai.c index c94201e..37184ff 100644 --- a/arch/arm/mach-shmobile/board-genmai.c +++ b/arch/arm/mach-shmobile/board-genmai.c @@ -46,7 +46,6 @@ static const struct resource ether_resources[] __initconst = { }; static const struct platform_device_info ether_info __initconst = { - .parent = &platform_bus, .name = "r7s72100-ether", .id = -1, .res = ether_resources, @@ -76,7 +75,7 @@ static const struct rspi_plat_data rspi_pdata __initconst = { }; #define r7s72100_register_rspi(idx) \ - platform_device_register_resndata(&platform_bus, "rspi-rz", idx, \ + platform_device_register_resndata(NULL, "rspi-rz", idx, \ rspi##idx##_resources, \ ARRAY_SIZE(rspi##idx##_resources), \ &rspi_pdata, sizeof(rspi_pdata)) @@ -118,7 +117,7 @@ R7S72100_SCIF(6, 0xe800a000, gic_iid(245)); R7S72100_SCIF(7, 0xe800a800, gic_iid(249)); #define r7s72100_register_scif(index) \ - platform_device_register_resndata(&platform_bus, "sh-sci", index, \ + platform_device_register_resndata(NULL, "sh-sci", index, \ scif##index##_resources, \ ARRAY_SIZE(scif##index##_resources), \ &scif##index##_platform_data, \ diff --git a/arch/arm/mach-shmobile/board-koelsch.c b/arch/arm/mach-shmobile/board-koelsch.c index c6c6889..d3aa6ae 100644 --- a/arch/arm/mach-shmobile/board-koelsch.c +++ b/arch/arm/mach-shmobile/board-koelsch.c @@ -118,7 +118,6 @@ static const struct resource ether_resources[] __initconst = { }; static const struct platform_device_info ether_info __initconst = { - .parent = &platform_bus, .name = "r8a7791-ether", .id = -1, .res = ether_resources, @@ -230,7 +229,6 @@ static const struct resource sata0_resources[] __initconst = { }; static const struct platform_device_info sata0_info __initconst = { - .parent = &platform_bus, .name = "sata-r8a7791", .id = 0, .res = sata0_resources, @@ -439,13 +437,13 @@ static void __init koelsch_add_standard_devices(void) r8a7791_pinmux_init(); r8a7791_add_standard_devices(); platform_device_register_full(ðer_info); - platform_device_register_data(&platform_bus, "leds-gpio", -1, + platform_device_register_data(NULL, "leds-gpio", -1, &koelsch_leds_pdata, sizeof(koelsch_leds_pdata)); - platform_device_register_data(&platform_bus, "gpio-keys", -1, + platform_device_register_data(NULL, "gpio-keys", -1, &koelsch_keys_pdata, sizeof(koelsch_keys_pdata)); - platform_device_register_resndata(&platform_bus, "qspi", 0, + platform_device_register_resndata(NULL, "qspi", 0, qspi_resources, ARRAY_SIZE(qspi_resources), &qspi_pdata, sizeof(qspi_pdata)); @@ -460,28 +458,28 @@ static void __init koelsch_add_standard_devices(void) koelsch_add_i2c(4); koelsch_add_i2c(5); - platform_device_register_data(&platform_bus, "reg-fixed-voltage", 0, + platform_device_register_data(NULL, "reg-fixed-voltage", 0, &vcc_sdhi0_info, sizeof(struct fixed_voltage_config)); - platform_device_register_data(&platform_bus, "reg-fixed-voltage", 1, + platform_device_register_data(NULL, "reg-fixed-voltage", 1, &vcc_sdhi1_info, sizeof(struct fixed_voltage_config)); - platform_device_register_data(&platform_bus, "reg-fixed-voltage", 2, + platform_device_register_data(NULL, "reg-fixed-voltage", 2, &vcc_sdhi2_info, sizeof(struct fixed_voltage_config)); - platform_device_register_data(&platform_bus, "gpio-regulator", 0, + platform_device_register_data(NULL, "gpio-regulator", 0, &vccq_sdhi0_info, sizeof(struct gpio_regulator_config)); - platform_device_register_data(&platform_bus, "gpio-regulator", 1, + platform_device_register_data(NULL, "gpio-regulator", 1, &vccq_sdhi1_info, sizeof(struct gpio_regulator_config)); - platform_device_register_data(&platform_bus, "gpio-regulator", 2, + platform_device_register_data(NULL, "gpio-regulator", 2, &vccq_sdhi2_info, sizeof(struct gpio_regulator_config)); - platform_device_register_resndata(&platform_bus, "sh_mobile_sdhi", 0, + platform_device_register_resndata(NULL, "sh_mobile_sdhi", 0, sdhi0_resources, ARRAY_SIZE(sdhi0_resources), &sdhi0_info, sizeof(struct sh_mobile_sdhi_info)); - platform_device_register_resndata(&platform_bus, "sh_mobile_sdhi", 1, + platform_device_register_resndata(NULL, "sh_mobile_sdhi", 1, sdhi1_resources, ARRAY_SIZE(sdhi1_resources), &sdhi1_info, sizeof(struct sh_mobile_sdhi_info)); - platform_device_register_resndata(&platform_bus, "sh_mobile_sdhi", 2, + platform_device_register_resndata(NULL, "sh_mobile_sdhi", 2, sdhi2_resources, ARRAY_SIZE(sdhi2_resources), &sdhi2_info, sizeof(struct sh_mobile_sdhi_info)); diff --git a/arch/arm/mach-shmobile/board-lager.c b/arch/arm/mach-shmobile/board-lager.c index f8b1e05..d182961 100644 --- a/arch/arm/mach-shmobile/board-lager.c +++ b/arch/arm/mach-shmobile/board-lager.c @@ -277,7 +277,6 @@ static const struct resource ether_resources[] __initconst = { }; static const struct platform_device_info ether_info __initconst = { - .parent = &platform_bus, .name = "r8a7790-ether", .id = -1, .res = ether_resources, @@ -354,7 +353,6 @@ static void __init lager_add_vin_device(unsigned idx, struct rcar_vin_platform_data *pdata) { struct platform_device_info vin_info = { - .parent = &platform_bus, .name = "r8a7790-vin", .id = idx, .res = &vin_resources[idx * 2], @@ -391,7 +389,7 @@ LAGER_CAMERA(1, "adv7180", 0x20, NULL, RCAR_VIN_BT656); static void __init lager_add_camera1_device(void) { - platform_device_register_data(&platform_bus, "soc-camera-pdrv", 1, + platform_device_register_data(NULL, "soc-camera-pdrv", 1, &cam1_link, sizeof(cam1_link)); lager_add_vin_device(1, &vin1_pdata); } @@ -403,7 +401,6 @@ static const struct resource sata1_resources[] __initconst = { }; static const struct platform_device_info sata1_info __initconst = { - .parent = &platform_bus, .name = "sata-r8a7790", .id = 1, .res = sata1_resources, @@ -533,7 +530,7 @@ static struct usbhs_private usbhs_priv __initdata = { static void __init lager_register_usbhs(void) { usb_bind_phy("renesas_usbhs", 0, "usb_phy_rcar_gen2"); - platform_device_register_resndata(&platform_bus, + platform_device_register_resndata(NULL, "renesas_usbhs", -1, usbhs_resources, ARRAY_SIZE(usbhs_resources), @@ -608,7 +605,6 @@ static struct asoc_simple_card_info rsnd_card_info = { static void __init lager_add_rsnd_device(void) { struct platform_device_info cardinfo = { - .parent = &platform_bus, .name = "asoc-simple-card", .id = -1, .data = &rsnd_card_info, @@ -620,7 +616,7 @@ static void __init lager_add_rsnd_device(void) ARRAY_SIZE(i2c2_devices)); platform_device_register_resndata( - &platform_bus, "rcar_sound", -1, + NULL, "rcar_sound", -1, rsnd_resources, ARRAY_SIZE(rsnd_resources), &rsnd_info, sizeof(rsnd_info)); @@ -663,7 +659,6 @@ static const struct resource pci1_resources[] __initconst = { }; static const struct platform_device_info pci1_info __initconst = { - .parent = &platform_bus, .name = "pci-rcar-gen2", .id = 1, .res = pci1_resources, @@ -684,7 +679,6 @@ static const struct resource pci2_resources[] __initconst = { }; static const struct platform_device_info pci2_info __initconst = { - .parent = &platform_bus, .name = "pci-rcar-gen2", .id = 2, .res = pci2_resources, @@ -795,16 +789,16 @@ static void __init lager_add_standard_devices(void) r8a7790_pinmux_init(); r8a7790_add_standard_devices(); - platform_device_register_data(&platform_bus, "leds-gpio", -1, + platform_device_register_data(NULL, "leds-gpio", -1, &lager_leds_pdata, sizeof(lager_leds_pdata)); - platform_device_register_data(&platform_bus, "gpio-keys", -1, + platform_device_register_data(NULL, "gpio-keys", -1, &lager_keys_pdata, sizeof(lager_keys_pdata)); regulator_register_always_on(fixed_regulator_idx++, "fixed-3.3V", fixed3v3_power_consumers, ARRAY_SIZE(fixed3v3_power_consumers), 3300000); - platform_device_register_resndata(&platform_bus, "sh_mmcif", 1, + platform_device_register_resndata(NULL, "sh_mmcif", 1, mmcif1_resources, ARRAY_SIZE(mmcif1_resources), &mmcif1_pdata, sizeof(mmcif1_pdata)); @@ -812,27 +806,27 @@ static void __init lager_add_standard_devices(void) lager_add_du_device(); - platform_device_register_resndata(&platform_bus, "qspi", 0, + platform_device_register_resndata(NULL, "qspi", 0, qspi_resources, ARRAY_SIZE(qspi_resources), &qspi_pdata, sizeof(qspi_pdata)); spi_register_board_info(spi_info, ARRAY_SIZE(spi_info)); - platform_device_register_data(&platform_bus, "reg-fixed-voltage", fixed_regulator_idx++, + platform_device_register_data(NULL, "reg-fixed-voltage", fixed_regulator_idx++, &vcc_sdhi0_info, sizeof(struct fixed_voltage_config)); - platform_device_register_data(&platform_bus, "reg-fixed-voltage", fixed_regulator_idx++, + platform_device_register_data(NULL, "reg-fixed-voltage", fixed_regulator_idx++, &vcc_sdhi2_info, sizeof(struct fixed_voltage_config)); - platform_device_register_data(&platform_bus, "gpio-regulator", gpio_regulator_idx++, + platform_device_register_data(NULL, "gpio-regulator", gpio_regulator_idx++, &vccq_sdhi0_info, sizeof(struct gpio_regulator_config)); - platform_device_register_data(&platform_bus, "gpio-regulator", gpio_regulator_idx++, + platform_device_register_data(NULL, "gpio-regulator", gpio_regulator_idx++, &vccq_sdhi2_info, sizeof(struct gpio_regulator_config)); lager_add_camera1_device(); platform_device_register_full(&sata1_info); - platform_device_register_resndata(&platform_bus, "usb_phy_rcar_gen2", + platform_device_register_resndata(NULL, "usb_phy_rcar_gen2", -1, usbhs_phy_resources, ARRAY_SIZE(usbhs_phy_resources), &usbhs_phy_pdata, @@ -843,10 +837,10 @@ static void __init lager_add_standard_devices(void) lager_add_rsnd_device(); - platform_device_register_resndata(&platform_bus, "sh_mobile_sdhi", 0, + platform_device_register_resndata(NULL, "sh_mobile_sdhi", 0, sdhi0_resources, ARRAY_SIZE(sdhi0_resources), &sdhi0_info, sizeof(struct sh_mobile_sdhi_info)); - platform_device_register_resndata(&platform_bus, "sh_mobile_sdhi", 2, + platform_device_register_resndata(NULL, "sh_mobile_sdhi", 2, sdhi2_resources, ARRAY_SIZE(sdhi2_resources), &sdhi2_info, sizeof(struct sh_mobile_sdhi_info)); } diff --git a/arch/arm/mach-shmobile/board-marzen.c b/arch/arm/mach-shmobile/board-marzen.c index d832a44..6ed324c 100644 --- a/arch/arm/mach-shmobile/board-marzen.c +++ b/arch/arm/mach-shmobile/board-marzen.c @@ -272,7 +272,6 @@ static struct resource vin##idx##_resources[] __initdata = { \ }; \ \ static struct platform_device_info vin##idx##_info __initdata = { \ - .parent = &platform_bus, \ .name = "r8a7779-vin", \ .id = idx, \ .res = vin##idx##_resources, \ diff --git a/arch/arm/mach-shmobile/setup-r7s72100.c b/arch/arm/mach-shmobile/setup-r7s72100.c index 412e179..3885a59 100644 --- a/arch/arm/mach-shmobile/setup-r7s72100.c +++ b/arch/arm/mach-shmobile/setup-r7s72100.c @@ -33,7 +33,7 @@ static struct resource mtu2_resources[] __initdata = { }; #define r7s72100_register_mtu2() \ - platform_device_register_resndata(&platform_bus, "sh-mtu2", \ + platform_device_register_resndata(NULL, "sh-mtu2", \ -1, mtu2_resources, \ ARRAY_SIZE(mtu2_resources), \ NULL, 0) diff --git a/arch/arm/mach-shmobile/setup-r8a73a4.c b/arch/arm/mach-shmobile/setup-r8a73a4.c index 9333770..aaaaf6e 100644 --- a/arch/arm/mach-shmobile/setup-r8a73a4.c +++ b/arch/arm/mach-shmobile/setup-r8a73a4.c @@ -68,7 +68,7 @@ R8A73A4_SCIFB(4, 0xe6ce0000, gic_spi(150)); /* SCIFB2 */ R8A73A4_SCIFB(5, 0xe6cf0000, gic_spi(151)); /* SCIFB3 */ #define r8a73a4_register_scif(index) \ - platform_device_register_resndata(&platform_bus, "sh-sci", index, \ + platform_device_register_resndata(NULL, "sh-sci", index, \ scif##index##_resources, \ ARRAY_SIZE(scif##index##_resources), \ &scif##index##_platform_data, \ @@ -149,7 +149,7 @@ static const struct resource irqc1_resources[] = { }; #define r8a73a4_register_irqc(idx) \ - platform_device_register_resndata(&platform_bus, "renesas_irqc", \ + platform_device_register_resndata(NULL, "renesas_irqc", \ idx, irqc##idx##_resources, \ ARRAY_SIZE(irqc##idx##_resources), \ &irqc##idx##_data, \ @@ -179,7 +179,7 @@ static struct resource cmt1_resources[] = { }; #define r8a7790_register_cmt(idx) \ - platform_device_register_resndata(&platform_bus, "sh-cmt-48-gen2", \ + platform_device_register_resndata(NULL, "sh-cmt-48-gen2", \ idx, cmt##idx##_resources, \ ARRAY_SIZE(cmt##idx##_resources), \ &cmt##idx##_platform_data, \ @@ -280,7 +280,7 @@ static struct resource dma_resources[] = { }; #define r8a73a4_register_dmac() \ - platform_device_register_resndata(&platform_bus, "sh-dma-engine", 0, \ + platform_device_register_resndata(NULL, "sh-dma-engine", 0, \ dma_resources, ARRAY_SIZE(dma_resources), \ &dma_pdata, sizeof(dma_pdata)) diff --git a/arch/arm/mach-shmobile/setup-r8a7778.c b/arch/arm/mach-shmobile/setup-r8a7778.c index d311ef9..5de7b33 100644 --- a/arch/arm/mach-shmobile/setup-r8a7778.c +++ b/arch/arm/mach-shmobile/setup-r8a7778.c @@ -64,7 +64,7 @@ R8A7778_SCIF(4, 0xffe44000, gic_iid(0x6a)); R8A7778_SCIF(5, 0xffe45000, gic_iid(0x6b)); #define r8a7778_register_scif(index) \ - platform_device_register_resndata(&platform_bus, "sh-sci", index, \ + platform_device_register_resndata(NULL, "sh-sci", index, \ scif##index##_resources, \ ARRAY_SIZE(scif##index##_resources), \ &scif##index##_platform_data, \ @@ -84,7 +84,7 @@ static struct resource sh_tmu0_resources[] = { #define r8a7778_register_tmu(idx) \ platform_device_register_resndata( \ - &platform_bus, "sh-tmu", idx, \ + NULL, "sh-tmu", idx, \ sh_tmu##idx##_resources, \ ARRAY_SIZE(sh_tmu##idx##_resources), \ &sh_tmu##idx##_platform_data, \ @@ -173,7 +173,6 @@ static struct resource ohci_resources[] __initdata = { #define USB_PLATFORM_INFO(hci) \ static struct platform_device_info hci##_info __initdata = { \ - .parent = &platform_bus, \ .name = #hci "-platform", \ .id = -1, \ .res = hci##_resources, \ @@ -212,7 +211,7 @@ R8A7778_GPIO(4); #define r8a7778_register_gpio(idx) \ platform_device_register_resndata( \ - &platform_bus, "gpio_rcar", idx, \ + NULL, "gpio_rcar", idx, \ r8a7778_gpio##idx##_resources, \ ARRAY_SIZE(r8a7778_gpio##idx##_resources), \ &r8a7778_gpio##idx##_platform_data, \ @@ -496,8 +495,8 @@ static struct resource hpb_dmae_resources[] __initdata = { static void __init r8a7778_register_hpb_dmae(void) { - platform_device_register_resndata(&platform_bus, "hpb-dma-engine", -1, - hpb_dmae_resources, + platform_device_register_resndata(NULL, "hpb-dma-engine", + -1, hpb_dmae_resources, ARRAY_SIZE(hpb_dmae_resources), &dma_platform_data, sizeof(dma_platform_data)); @@ -565,7 +564,7 @@ void __init r8a7778_init_irq_extpin(int irlm) r8a7778_init_irq_extpin_dt(irlm); if (irlm) platform_device_register_resndata( - &platform_bus, "renesas_intc_irqpin", -1, + NULL, "renesas_intc_irqpin", -1, irqpin_resources, ARRAY_SIZE(irqpin_resources), &irqpin_platform_data, sizeof(irqpin_platform_data)); } diff --git a/arch/arm/mach-shmobile/setup-r8a7779.c b/arch/arm/mach-shmobile/setup-r8a7779.c index aba4ed6..9c79182 100644 --- a/arch/arm/mach-shmobile/setup-r8a7779.c +++ b/arch/arm/mach-shmobile/setup-r8a7779.c @@ -123,7 +123,7 @@ void __init r8a7779_init_irq_extpin(int irlm) r8a7779_init_irq_extpin_dt(irlm); if (irlm) platform_device_register_resndata( - &platform_bus, "renesas_intc_irqpin", -1, + NULL, "renesas_intc_irqpin", -1, irqpin0_resources, ARRAY_SIZE(irqpin0_resources), &irqpin0_platform_data, sizeof(irqpin0_platform_data)); } @@ -632,8 +632,8 @@ static struct resource hpb_dmae_resources[] __initdata = { static void __init r8a7779_register_hpb_dmae(void) { - platform_device_register_resndata(&platform_bus, "hpb-dma-engine", -1, - hpb_dmae_resources, + platform_device_register_resndata(NULL, "hpb-dma-engine", + -1, hpb_dmae_resources, ARRAY_SIZE(hpb_dmae_resources), &dma_platform_data, sizeof(dma_platform_data)); diff --git a/arch/arm/mach-shmobile/setup-r8a7790.c b/arch/arm/mach-shmobile/setup-r8a7790.c index 6bd08b1..10e6768 100644 --- a/arch/arm/mach-shmobile/setup-r8a7790.c +++ b/arch/arm/mach-shmobile/setup-r8a7790.c @@ -113,7 +113,7 @@ static struct resource r8a7790_audio_dmac_resources[] = { #define r8a7790_register_audio_dmac(id) \ platform_device_register_resndata( \ - &platform_bus, "sh-dma-engine", id, \ + NULL, "sh-dma-engine", id, \ &r8a7790_audio_dmac_resources[id * 3], 3, \ &r8a7790_audio_dmac_platform_data, \ sizeof(r8a7790_audio_dmac_platform_data)) @@ -149,7 +149,7 @@ R8A7790_GPIO(4); R8A7790_GPIO(5); #define r8a7790_register_gpio(idx) \ - platform_device_register_resndata(&platform_bus, "gpio_rcar", idx, \ + platform_device_register_resndata(NULL, "gpio_rcar", idx, \ r8a7790_gpio##idx##_resources, \ ARRAY_SIZE(r8a7790_gpio##idx##_resources), \ &r8a7790_gpio##idx##_platform_data, \ @@ -227,7 +227,7 @@ R8A7790_HSCIF(8, 0xe62c0000, gic_spi(154)); /* HSCIF0 */ R8A7790_HSCIF(9, 0xe62c8000, gic_spi(155)); /* HSCIF1 */ #define r8a7790_register_scif(index) \ - platform_device_register_resndata(&platform_bus, "sh-sci", index, \ + platform_device_register_resndata(NULL, "sh-sci", index, \ scif##index##_resources, \ ARRAY_SIZE(scif##index##_resources), \ &scif##index##_platform_data, \ @@ -246,7 +246,7 @@ static const struct resource irqc0_resources[] __initconst = { }; #define r8a7790_register_irqc(idx) \ - platform_device_register_resndata(&platform_bus, "renesas_irqc", \ + platform_device_register_resndata(NULL, "renesas_irqc", \ idx, irqc##idx##_resources, \ ARRAY_SIZE(irqc##idx##_resources), \ &irqc##idx##_data, \ @@ -273,7 +273,7 @@ static struct resource cmt0_resources[] = { }; #define r8a7790_register_cmt(idx) \ - platform_device_register_resndata(&platform_bus, "sh-cmt-48-gen2", \ + platform_device_register_resndata(NULL, "sh-cmt-48-gen2", \ idx, cmt##idx##_resources, \ ARRAY_SIZE(cmt##idx##_resources), \ &cmt##idx##_platform_data, \ diff --git a/arch/arm/mach-shmobile/setup-r8a7791.c b/arch/arm/mach-shmobile/setup-r8a7791.c index 04a96dd..fd54437 100644 --- a/arch/arm/mach-shmobile/setup-r8a7791.c +++ b/arch/arm/mach-shmobile/setup-r8a7791.c @@ -65,7 +65,7 @@ R8A7791_GPIO(6, 0xe6055400, 32); R8A7791_GPIO(7, 0xe6055800, 26); #define r8a7791_register_gpio(idx) \ - platform_device_register_resndata(&platform_bus, "gpio_rcar", idx, \ + platform_device_register_resndata(NULL, "gpio_rcar", idx, \ r8a7791_gpio##idx##_resources, \ ARRAY_SIZE(r8a7791_gpio##idx##_resources), \ &r8a7791_gpio##idx##_platform_data, \ @@ -122,7 +122,7 @@ R8A7791_SCIFA(13, 0xe6c78000, gic_spi(30)); /* SCIFA4 */ R8A7791_SCIFA(14, 0xe6c80000, gic_spi(31)); /* SCIFA5 */ #define r8a7791_register_scif(index) \ - platform_device_register_resndata(&platform_bus, "sh-sci", index, \ + platform_device_register_resndata(NULL, "sh-sci", index, \ scif##index##_resources, \ ARRAY_SIZE(scif##index##_resources), \ &scif##index##_platform_data, \ @@ -138,7 +138,7 @@ static struct resource cmt0_resources[] = { }; #define r8a7791_register_cmt(idx) \ - platform_device_register_resndata(&platform_bus, "sh-cmt-48-gen2", \ + platform_device_register_resndata(NULL, "sh-cmt-48-gen2", \ idx, cmt##idx##_resources, \ ARRAY_SIZE(cmt##idx##_resources), \ &cmt##idx##_platform_data, \ @@ -163,7 +163,7 @@ static struct resource irqc0_resources[] = { }; #define r8a7791_register_irqc(idx) \ - platform_device_register_resndata(&platform_bus, "renesas_irqc", \ + platform_device_register_resndata(NULL, "renesas_irqc", \ idx, irqc##idx##_resources, \ ARRAY_SIZE(irqc##idx##_resources), \ &irqc##idx##_data, \ diff --git a/arch/unicore32/kernel/puv3-core.c b/arch/unicore32/kernel/puv3-core.c index 254adee..438dd2e 100644 --- a/arch/unicore32/kernel/puv3-core.c +++ b/arch/unicore32/kernel/puv3-core.c @@ -272,7 +272,7 @@ void __init puv3_core_init(void) platform_device_register_simple("PKUnity-v3-UART", 1, puv3_uart1_resources, ARRAY_SIZE(puv3_uart1_resources)); platform_device_register_simple("PKUnity-v3-AC97", -1, NULL, 0); - platform_device_register_resndata(&platform_bus, "musb_hdrc", -1, + platform_device_register_resndata(NULL, "musb_hdrc", -1, puv3_usb_resources, ARRAY_SIZE(puv3_usb_resources), &puv3_usb_plat, sizeof(puv3_usb_plat)); } diff --git a/arch/unicore32/kernel/puv3-nb0916.c b/arch/unicore32/kernel/puv3-nb0916.c index 0c6618e..46ebfdc 100644 --- a/arch/unicore32/kernel/puv3-nb0916.c +++ b/arch/unicore32/kernel/puv3-nb0916.c @@ -112,13 +112,13 @@ int __init mach_nb0916_init(void) platform_device_register_simple("PKUnity-v3-I2C", -1, puv3_i2c_resources, ARRAY_SIZE(puv3_i2c_resources)); - platform_device_register_data(&platform_bus, "pwm-backlight", -1, + platform_device_register_data(NULL, "pwm-backlight", -1, &nb0916_backlight_data, sizeof(nb0916_backlight_data)); - platform_device_register_data(&platform_bus, "gpio-keys", -1, + platform_device_register_data(NULL, "gpio-keys", -1, &nb0916_gpio_button_data, sizeof(nb0916_gpio_button_data)); - platform_device_register_resndata(&platform_bus, "physmap-flash", -1, + platform_device_register_resndata(NULL, "physmap-flash", -1, &physmap_flash_resource, 1, &physmap_flash_data, sizeof(physmap_flash_data)); diff --git a/drivers/base/platform.c b/drivers/base/platform.c index eee48c4..f272603 100644 --- a/drivers/base/platform.c +++ b/drivers/base/platform.c @@ -30,8 +30,8 @@ /* For automatically allocated device IDs */ static DEFINE_IDA(platform_devid_ida); -struct device platform_bus = { - .init_name = "platform", +struct platform_device platform_bus = { + .name = "platform", }; EXPORT_SYMBOL_GPL(platform_bus); @@ -300,7 +300,7 @@ int platform_device_add(struct platform_device *pdev) return -EINVAL; if (!pdev->dev.parent) - pdev->dev.parent = &platform_bus; + pdev->dev.parent = &platform_bus.dev; pdev->dev.bus = &platform_bus_type; @@ -946,12 +946,18 @@ int __init platform_bus_init(void) early_platform_cleanup(); - error = device_register(&platform_bus); + dev_set_name(&platform_bus.dev, "%s", platform_bus.name); + error = device_register(&platform_bus.dev); if (error) return error; error = bus_register(&platform_bus_type); - if (error) - device_unregister(&platform_bus); + if (!error) { + platform_bus.dev.of_node = of_allnodes; + platform_bus.dev.bus = &platform_bus_type; + bus_add_device(&platform_bus.dev); + } else { + device_unregister(&platform_bus.dev); + } return error; } diff --git a/drivers/char/tile-srom.c b/drivers/char/tile-srom.c index bd37747..4e4b7a2 100644 --- a/drivers/char/tile-srom.c +++ b/drivers/char/tile-srom.c @@ -350,7 +350,7 @@ static int srom_setup_minor(struct srom_dev *srom, int index) SROM_PAGE_SIZE_OFF, sizeof(srom->page_size)) < 0) return -EIO; - dev = device_create(srom_class, &platform_bus, + dev = device_create(srom_class, &platform_bus.dev, MKDEV(srom_major, index), srom, "%d", index); return PTR_ERR_OR_ZERO(dev); } diff --git a/drivers/mmc/host/sdhci-pltfm.c b/drivers/mmc/host/sdhci-pltfm.c index 7e834fb..9a2b0d0 100644 --- a/drivers/mmc/host/sdhci-pltfm.c +++ b/drivers/mmc/host/sdhci-pltfm.c @@ -137,7 +137,7 @@ struct sdhci_host *sdhci_pltfm_init(struct platform_device *pdev, dev_err(&pdev->dev, "Invalid iomem size!\n"); /* Some PCI-based MFD need the parent here */ - if (pdev->dev.parent != &platform_bus && !np) + if (pdev->dev.parent != &platform_bus.dev && !np) host = sdhci_alloc_host(pdev->dev.parent, sizeof(struct sdhci_pltfm_host) + priv_size); else diff --git a/drivers/scsi/hosts.c b/drivers/scsi/hosts.c index 3cbb57a..c14c36f 100644 --- a/drivers/scsi/hosts.c +++ b/drivers/scsi/hosts.c @@ -218,7 +218,7 @@ int scsi_add_host_with_dma(struct Scsi_Host *shost, struct device *dev, goto fail; if (!shost->shost_gendev.parent) - shost->shost_gendev.parent = dev ? dev : &platform_bus; + shost->shost_gendev.parent = dev ? dev : &platform_bus.dev; if (!dma_dev) dma_dev = shost->shost_gendev.parent; diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h index 16f6654..a99032a 100644 --- a/include/linux/platform_device.h +++ b/include/linux/platform_device.h @@ -44,7 +44,7 @@ extern int platform_device_register(struct platform_device *); extern void platform_device_unregister(struct platform_device *); extern struct bus_type platform_bus_type; -extern struct device platform_bus; +extern struct platform_device platform_bus; extern void arch_setup_pdev_archdata(struct platform_device *); extern struct resource *platform_get_resource(struct platform_device *, -- 1.9.1 ^ permalink raw reply related [flat|nested] 48+ messages in thread
* [PATCH v3] platform: Make platform_bus device a platform device 2014-07-22 17:55 ` [PATCH v3] " Pawel Moll @ 2014-07-22 18:01 ` Pawel Moll 2014-07-22 18:15 ` Greg Kroah-Hartman 2014-07-22 19:46 ` Olof Johansson 2014-07-22 22:16 ` Greg Kroah-Hartman 2 siblings, 1 reply; 48+ messages in thread From: Pawel Moll @ 2014-07-22 18:01 UTC (permalink / raw) To: linux-arm-kernel On Tue, 2014-07-22 at 18:55 +0100, Pawel Moll wrote: > * replaced references to platform_bus.dev with NULL > in places where it shouldn't make any difference So now the leftovers... > diff --git a/arch/arm/mach-imx/devices/devices.c b/arch/arm/mach-imx/devices/devices.c > index 1b4366a..48c3817 100644 > --- a/arch/arm/mach-imx/devices/devices.c > +++ b/arch/arm/mach-imx/devices/devices.c > @@ -24,12 +24,12 @@ > > struct device mxc_aips_bus = { > .init_name = "mxc_aips", > - .parent = &platform_bus, > + .parent = &platform_bus.dev, > }; > > struct device mxc_ahb_bus = { > .init_name = "mxc_ahb", > - .parent = &platform_bus, > + .parent = &platform_bus.dev, > }; > > int __init mxc_device_init(void) Seems that the author meant to have those two bus devices hanging from the platform_bus in device hierarchy. Seems fair enough to me. > diff --git a/drivers/char/tile-srom.c b/drivers/char/tile-srom.c > index bd37747..4e4b7a2 100644 > --- a/drivers/char/tile-srom.c > +++ b/drivers/char/tile-srom.c > @@ -350,7 +350,7 @@ static int srom_setup_minor(struct srom_dev *srom, int index) > SROM_PAGE_SIZE_OFF, sizeof(srom->page_size)) < 0) > return -EIO; > > - dev = device_create(srom_class, &platform_bus, > + dev = device_create(srom_class, &platform_bus.dev, > MKDEV(srom_major, index), srom, "%d", index); > return PTR_ERR_OR_ZERO(dev); > } Again, non-platform device placed in the hierarchy. > diff --git a/drivers/mmc/host/sdhci-pltfm.c b/drivers/mmc/host/sdhci-pltfm.c > index 7e834fb..9a2b0d0 100644 > --- a/drivers/mmc/host/sdhci-pltfm.c > +++ b/drivers/mmc/host/sdhci-pltfm.c > @@ -137,7 +137,7 @@ struct sdhci_host *sdhci_pltfm_init(struct platform_device *pdev, > dev_err(&pdev->dev, "Invalid iomem size!\n"); > > /* Some PCI-based MFD need the parent here */ > - if (pdev->dev.parent != &platform_bus && !np) > + if (pdev->dev.parent != &platform_bus.dev && !np) > host = sdhci_alloc_host(pdev->dev.parent, > sizeof(struct sdhci_pltfm_host) + priv_size); > else Special treatment for non-platform devices. > diff --git a/drivers/scsi/hosts.c b/drivers/scsi/hosts.c > index 3cbb57a..c14c36f 100644 > --- a/drivers/scsi/hosts.c > +++ b/drivers/scsi/hosts.c > @@ -218,7 +218,7 @@ int scsi_add_host_with_dma(struct Scsi_Host *shost, struct device *dev, > goto fail; > > if (!shost->shost_gendev.parent) > - shost->shost_gendev.parent = dev ? dev : &platform_bus; > + shost->shost_gendev.parent = dev ? dev : &platform_bus.dev; > if (!dma_dev) > dma_dev = shost->shost_gendev.parent; > shost_gendev is a generic (as in struct device, non-platform one) device, that is being explicitly placed in the hierarchy. So it makes it 4, not 3 ;-) places where referencing platform_bus *maybe* makes some sense. Pawel ^ permalink raw reply [flat|nested] 48+ messages in thread
* [PATCH v3] platform: Make platform_bus device a platform device 2014-07-22 18:01 ` Pawel Moll @ 2014-07-22 18:15 ` Greg Kroah-Hartman 2014-07-23 17:16 ` Pawel Moll 0 siblings, 1 reply; 48+ messages in thread From: Greg Kroah-Hartman @ 2014-07-22 18:15 UTC (permalink / raw) To: linux-arm-kernel On Tue, Jul 22, 2014 at 07:01:09PM +0100, Pawel Moll wrote: > On Tue, 2014-07-22 at 18:55 +0100, Pawel Moll wrote: > > * replaced references to platform_bus.dev with NULL > > in places where it shouldn't make any difference > > So now the leftovers... > > > diff --git a/arch/arm/mach-imx/devices/devices.c b/arch/arm/mach-imx/devices/devices.c > > index 1b4366a..48c3817 100644 > > --- a/arch/arm/mach-imx/devices/devices.c > > +++ b/arch/arm/mach-imx/devices/devices.c > > @@ -24,12 +24,12 @@ > > > > struct device mxc_aips_bus = { > > .init_name = "mxc_aips", > > - .parent = &platform_bus, > > + .parent = &platform_bus.dev, > > }; > > > > struct device mxc_ahb_bus = { > > .init_name = "mxc_ahb", > > - .parent = &platform_bus, > > + .parent = &platform_bus.dev, > > }; > > > > int __init mxc_device_init(void) > > Seems that the author meant to have those two bus devices hanging from > the platform_bus in device hierarchy. Seems fair enough to me. No, not at all, this is a different bus, put the root bus at the root of the sysfs tree, not at some "arbritrary" point on a platform device. > > diff --git a/drivers/char/tile-srom.c b/drivers/char/tile-srom.c > > index bd37747..4e4b7a2 100644 > > --- a/drivers/char/tile-srom.c > > +++ b/drivers/char/tile-srom.c > > @@ -350,7 +350,7 @@ static int srom_setup_minor(struct srom_dev *srom, int index) > > SROM_PAGE_SIZE_OFF, sizeof(srom->page_size)) < 0) > > return -EIO; > > > > - dev = device_create(srom_class, &platform_bus, > > + dev = device_create(srom_class, &platform_bus.dev, > > MKDEV(srom_major, index), srom, "%d", index); > > return PTR_ERR_OR_ZERO(dev); > > } > > Again, non-platform device placed in the hierarchy. Again, not ok. If it's a platform device, it's a platform device, and make it one. If it isn't, like this one, make it a virtual device and pass NULL here. > > diff --git a/drivers/mmc/host/sdhci-pltfm.c b/drivers/mmc/host/sdhci-pltfm.c > > index 7e834fb..9a2b0d0 100644 > > --- a/drivers/mmc/host/sdhci-pltfm.c > > +++ b/drivers/mmc/host/sdhci-pltfm.c > > @@ -137,7 +137,7 @@ struct sdhci_host *sdhci_pltfm_init(struct platform_device *pdev, > > dev_err(&pdev->dev, "Invalid iomem size!\n"); > > > > /* Some PCI-based MFD need the parent here */ > > - if (pdev->dev.parent != &platform_bus && !np) > > + if (pdev->dev.parent != &platform_bus.dev && !np) > > host = sdhci_alloc_host(pdev->dev.parent, > > sizeof(struct sdhci_pltfm_host) + priv_size); > > else > > Special treatment for non-platform devices. Ugh, why should you care? I don't understand the logic here. > > diff --git a/drivers/scsi/hosts.c b/drivers/scsi/hosts.c > > index 3cbb57a..c14c36f 100644 > > --- a/drivers/scsi/hosts.c > > +++ b/drivers/scsi/hosts.c > > @@ -218,7 +218,7 @@ int scsi_add_host_with_dma(struct Scsi_Host *shost, struct device *dev, > > goto fail; > > > > if (!shost->shost_gendev.parent) > > - shost->shost_gendev.parent = dev ? dev : &platform_bus; > > + shost->shost_gendev.parent = dev ? dev : &platform_bus.dev; > > if (!dma_dev) > > dma_dev = shost->shost_gendev.parent; > > > > shost_gendev is a generic (as in struct device, non-platform one) > device, that is being explicitly placed in the hierarchy. Then make it a virtual device, as that's what it is, replace this with NULL. > So it makes it 4, not 3 ;-) places where referencing platform_bus > *maybe* makes some sense. Nope, see above :) thanks, greg k-h ^ permalink raw reply [flat|nested] 48+ messages in thread
* [PATCH v3] platform: Make platform_bus device a platform device 2014-07-22 18:15 ` Greg Kroah-Hartman @ 2014-07-23 17:16 ` Pawel Moll 2014-07-23 19:34 ` Greg Kroah-Hartman 0 siblings, 1 reply; 48+ messages in thread From: Pawel Moll @ 2014-07-23 17:16 UTC (permalink / raw) To: linux-arm-kernel On Tue, 2014-07-22 at 19:15 +0100, Greg Kroah-Hartman wrote: > > > diff --git a/arch/arm/mach-imx/devices/devices.c b/arch/arm/mach-imx/devices/devices.c > > > index 1b4366a..48c3817 100644 > > > --- a/arch/arm/mach-imx/devices/devices.c > > > +++ b/arch/arm/mach-imx/devices/devices.c > > > @@ -24,12 +24,12 @@ > > > > > > struct device mxc_aips_bus = { > > > .init_name = "mxc_aips", > > > - .parent = &platform_bus, > > > + .parent = &platform_bus.dev, > > > }; > > > > > > struct device mxc_ahb_bus = { > > > .init_name = "mxc_ahb", > > > - .parent = &platform_bus, > > > + .parent = &platform_bus.dev, > > > }; > > > > > > int __init mxc_device_init(void) > > > > Seems that the author meant to have those two bus devices hanging from > > the platform_bus in device hierarchy. Seems fair enough to me. > > No, not at all, this is a different bus, put the root bus at the root of > the sysfs tree, not at some "arbritrary" point on a platform device. I think the author considers platform bus is understood as a representation of the MMIO space (and he's not alone). So then he wants to represent the physical hierarchy of the interconnect to get it in separate places in the /sys/devices/* tree. Whether it's a good thing to do or not, have no strong opinion, but can understand his approach. I don't think it's a big deal either way. > > > diff --git a/drivers/char/tile-srom.c b/drivers/char/tile-srom.c > > > index bd37747..4e4b7a2 100644 > > > --- a/drivers/char/tile-srom.c > > > +++ b/drivers/char/tile-srom.c > > > @@ -350,7 +350,7 @@ static int srom_setup_minor(struct srom_dev *srom, int index) > > > SROM_PAGE_SIZE_OFF, sizeof(srom->page_size)) < 0) > > > return -EIO; > > > > > > - dev = device_create(srom_class, &platform_bus, > > > + dev = device_create(srom_class, &platform_bus.dev, > > > MKDEV(srom_major, index), srom, "%d", index); > > > return PTR_ERR_OR_ZERO(dev); > > > } > > > > Again, non-platform device placed in the hierarchy. > > Again, not ok. If it's a platform device, it's a platform device, and > make it one. If it isn't, like this one, make it a virtual device and > pass NULL here. Yeah, I can't disagree here. > > > diff --git a/drivers/mmc/host/sdhci-pltfm.c b/drivers/mmc/host/sdhci-pltfm.c > > > index 7e834fb..9a2b0d0 100644 > > > --- a/drivers/mmc/host/sdhci-pltfm.c > > > +++ b/drivers/mmc/host/sdhci-pltfm.c > > > @@ -137,7 +137,7 @@ struct sdhci_host *sdhci_pltfm_init(struct platform_device *pdev, > > > dev_err(&pdev->dev, "Invalid iomem size!\n"); > > > > > > /* Some PCI-based MFD need the parent here */ > > > - if (pdev->dev.parent != &platform_bus && !np) > > > + if (pdev->dev.parent != &platform_bus.dev && !np) > > > host = sdhci_alloc_host(pdev->dev.parent, > > > sizeof(struct sdhci_pltfm_host) + priv_size); > > > else > > > > Special treatment for non-platform devices. > > Ugh, why should you care? I don't understand the logic here. Neither do I, but maybe there is' some :-) I definitely wouldn't like to change the behaviour without checking with the maintainers. > > > diff --git a/drivers/scsi/hosts.c b/drivers/scsi/hosts.c > > > index 3cbb57a..c14c36f 100644 > > > --- a/drivers/scsi/hosts.c > > > +++ b/drivers/scsi/hosts.c > > > @@ -218,7 +218,7 @@ int scsi_add_host_with_dma(struct Scsi_Host *shost, struct device *dev, > > > goto fail; > > > > > > if (!shost->shost_gendev.parent) > > > - shost->shost_gendev.parent = dev ? dev : &platform_bus; > > > + shost->shost_gendev.parent = dev ? dev : &platform_bus.dev; > > > if (!dma_dev) > > > dma_dev = shost->shost_gendev.parent; > > > > > > > shost_gendev is a generic (as in struct device, non-platform one) > > device, that is being explicitly placed in the hierarchy. > > Then make it a virtual device, as that's what it is, replace this with > NULL. Makes sense to me, I just wonder what the author meant. > > So it makes it 4, not 3 ;-) places where referencing platform_bus > > *maybe* makes some sense. > > Nope, see above :) Let me just point out that I'm just playing the devil's advocate here :-) Pawel ^ permalink raw reply [flat|nested] 48+ messages in thread
* [PATCH v3] platform: Make platform_bus device a platform device 2014-07-23 17:16 ` Pawel Moll @ 2014-07-23 19:34 ` Greg Kroah-Hartman 2014-07-24 17:12 ` Pawel Moll 0 siblings, 1 reply; 48+ messages in thread From: Greg Kroah-Hartman @ 2014-07-23 19:34 UTC (permalink / raw) To: linux-arm-kernel On Wed, Jul 23, 2014 at 06:16:02PM +0100, Pawel Moll wrote: > On Tue, 2014-07-22 at 19:15 +0100, Greg Kroah-Hartman wrote: > > > > diff --git a/arch/arm/mach-imx/devices/devices.c b/arch/arm/mach-imx/devices/devices.c > > > > index 1b4366a..48c3817 100644 > > > > --- a/arch/arm/mach-imx/devices/devices.c > > > > +++ b/arch/arm/mach-imx/devices/devices.c > > > > @@ -24,12 +24,12 @@ > > > > > > > > struct device mxc_aips_bus = { > > > > .init_name = "mxc_aips", > > > > - .parent = &platform_bus, > > > > + .parent = &platform_bus.dev, > > > > }; > > > > > > > > struct device mxc_ahb_bus = { > > > > .init_name = "mxc_ahb", > > > > - .parent = &platform_bus, > > > > + .parent = &platform_bus.dev, > > > > }; > > > > > > > > int __init mxc_device_init(void) > > > > > > Seems that the author meant to have those two bus devices hanging from > > > the platform_bus in device hierarchy. Seems fair enough to me. > > > > No, not at all, this is a different bus, put the root bus at the root of > > the sysfs tree, not at some "arbritrary" point on a platform device. > > I think the author considers platform bus is understood as a > representation of the MMIO space (and he's not alone). So then he wants > to represent the physical hierarchy of the interconnect to get it in > separate places in the /sys/devices/* tree. That's fine, but again, it's not a "child" of the platform bus. Otherwise you could argue that all busses should belong under the platform bus as well, which isn't going to happen. > Whether it's a good thing to do or not, have no strong opinion, but can > understand his approach. I don't think it's a big deal either way. Great, make it NULL :) > > > > diff --git a/drivers/char/tile-srom.c b/drivers/char/tile-srom.c > > > > index bd37747..4e4b7a2 100644 > > > > --- a/drivers/char/tile-srom.c > > > > +++ b/drivers/char/tile-srom.c > > > > @@ -350,7 +350,7 @@ static int srom_setup_minor(struct srom_dev *srom, int index) > > > > SROM_PAGE_SIZE_OFF, sizeof(srom->page_size)) < 0) > > > > return -EIO; > > > > > > > > - dev = device_create(srom_class, &platform_bus, > > > > + dev = device_create(srom_class, &platform_bus.dev, > > > > MKDEV(srom_major, index), srom, "%d", index); > > > > return PTR_ERR_OR_ZERO(dev); > > > > } > > > > > > Again, non-platform device placed in the hierarchy. > > > > Again, not ok. If it's a platform device, it's a platform device, and > > make it one. If it isn't, like this one, make it a virtual device and > > pass NULL here. > > Yeah, I can't disagree here. > > > > > diff --git a/drivers/mmc/host/sdhci-pltfm.c b/drivers/mmc/host/sdhci-pltfm.c > > > > index 7e834fb..9a2b0d0 100644 > > > > --- a/drivers/mmc/host/sdhci-pltfm.c > > > > +++ b/drivers/mmc/host/sdhci-pltfm.c > > > > @@ -137,7 +137,7 @@ struct sdhci_host *sdhci_pltfm_init(struct platform_device *pdev, > > > > dev_err(&pdev->dev, "Invalid iomem size!\n"); > > > > > > > > /* Some PCI-based MFD need the parent here */ > > > > - if (pdev->dev.parent != &platform_bus && !np) > > > > + if (pdev->dev.parent != &platform_bus.dev && !np) > > > > host = sdhci_alloc_host(pdev->dev.parent, > > > > sizeof(struct sdhci_pltfm_host) + priv_size); > > > > else > > > > > > Special treatment for non-platform devices. > > > > Ugh, why should you care? I don't understand the logic here. > > Neither do I, but maybe there is' some :-) I definitely wouldn't like to > change the behaviour without checking with the maintainers. Then let's ask :) > > > > diff --git a/drivers/scsi/hosts.c b/drivers/scsi/hosts.c > > > > index 3cbb57a..c14c36f 100644 > > > > --- a/drivers/scsi/hosts.c > > > > +++ b/drivers/scsi/hosts.c > > > > @@ -218,7 +218,7 @@ int scsi_add_host_with_dma(struct Scsi_Host *shost, struct device *dev, > > > > goto fail; > > > > > > > > if (!shost->shost_gendev.parent) > > > > - shost->shost_gendev.parent = dev ? dev : &platform_bus; > > > > + shost->shost_gendev.parent = dev ? dev : &platform_bus.dev; > > > > if (!dma_dev) > > > > dma_dev = shost->shost_gendev.parent; > > > > > > > > > > shost_gendev is a generic (as in struct device, non-platform one) > > > device, that is being explicitly placed in the hierarchy. > > > > Then make it a virtual device, as that's what it is, replace this with > > NULL. > > Makes sense to me, I just wonder what the author meant. With scsi code, who knows :) > > > So it makes it 4, not 3 ;-) places where referencing platform_bus > > > *maybe* makes some sense. > > > > Nope, see above :) > > Let me just point out that I'm just playing the devil's advocate > here :-) Of course, I'm not "shooting the messenger" at all, just pointing out problems with the code, you didn't write it. thanks, greg k-h ^ permalink raw reply [flat|nested] 48+ messages in thread
* [PATCH v3] platform: Make platform_bus device a platform device 2014-07-23 19:34 ` Greg Kroah-Hartman @ 2014-07-24 17:12 ` Pawel Moll 0 siblings, 0 replies; 48+ messages in thread From: Pawel Moll @ 2014-07-24 17:12 UTC (permalink / raw) To: linux-arm-kernel On Wed, 2014-07-23 at 20:34 +0100, Greg Kroah-Hartman wrote: > > > > > diff --git a/drivers/scsi/hosts.c b/drivers/scsi/hosts.c > > > > > index 3cbb57a..c14c36f 100644 > > > > > --- a/drivers/scsi/hosts.c > > > > > +++ b/drivers/scsi/hosts.c > > > > > @@ -218,7 +218,7 @@ int scsi_add_host_with_dma(struct Scsi_Host *shost, struct device *dev, > > > > > goto fail; > > > > > > > > > > if (!shost->shost_gendev.parent) > > > > > - shost->shost_gendev.parent = dev ? dev : &platform_bus; > > > > > + shost->shost_gendev.parent = dev ? dev : &platform_bus.dev; > > > > > if (!dma_dev) > > > > > dma_dev = shost->shost_gendev.parent; > > > > > > > > > > > > > shost_gendev is a generic (as in struct device, non-platform one) > > > > device, that is being explicitly placed in the hierarchy. > > > > > > Then make it a virtual device, as that's what it is, replace this with > > > NULL. > > > > Makes sense to me, I just wonder what the author meant. > > With scsi code, who knows :) Looking at this further, it seems that the main purpose here is to make sure that dma_dev is not NULL... So it's not just simply a case of s/&platform_bus/NULL/ - maybe the function should fail when !dma_dev? I'll split the patch so each case is separate and post them to relevant maintainers. Pawel ^ permalink raw reply [flat|nested] 48+ messages in thread
* [PATCH v3] platform: Make platform_bus device a platform device 2014-07-22 17:55 ` [PATCH v3] " Pawel Moll 2014-07-22 18:01 ` Pawel Moll @ 2014-07-22 19:46 ` Olof Johansson 2014-07-23 14:26 ` Pawel Moll 2014-07-22 22:16 ` Greg Kroah-Hartman 2 siblings, 1 reply; 48+ messages in thread From: Olof Johansson @ 2014-07-22 19:46 UTC (permalink / raw) To: linux-arm-kernel Hi, On Tue, Jul 22, 2014 at 10:55 AM, Pawel Moll <pawel.moll@arm.com> wrote: > ... describing the root of the device tree, so one can write > a platform driver initializing the platform. > > There has been a lot of references to platform_bus device where > it didn't make any sense, because simply using NULL as a parent > will make the device be adopted by the top level anyway. > > Signed-off-by: Pawel Moll <pawel.moll@arm.com> > --- > Changes since v2: > > * replaced references to platform_bus.dev with NULL > in places where it shouldn't make any difference > > Changes since v1: > > * rebased on top of v3.16-rc6 > > * fixed up all new explicit references to platform_bus, > with majority in mach-shmobile; 99% of them seem completely > useless and I was *very* tempted to replace them with > NULL - all reasons for and against this are welcomed > > arch/arm/mach-bcm/board_bcm21664.c | 3 +-- > arch/arm/mach-bcm/board_bcm281xx.c | 3 +-- > arch/arm/mach-clps711x/board-edb7211.c | 6 +++--- > arch/arm/mach-clps711x/board-p720t.c | 6 +++--- > arch/arm/mach-imx/devices/devices.c | 4 ++-- > arch/arm/mach-imx/mach-mx27ads.c | 2 +- > arch/arm/mach-shmobile/board-ape6evm.c | 14 +++++++------- > arch/arm/mach-shmobile/board-bockw.c | 19 ++++++++---------- > arch/arm/mach-shmobile/board-genmai.c | 5 ++--- > arch/arm/mach-shmobile/board-koelsch.c | 26 ++++++++++++------------- > arch/arm/mach-shmobile/board-lager.c | 34 ++++++++++++++------------------- > arch/arm/mach-shmobile/board-marzen.c | 1 - > arch/arm/mach-shmobile/setup-r7s72100.c | 2 +- > arch/arm/mach-shmobile/setup-r8a73a4.c | 8 ++++---- > arch/arm/mach-shmobile/setup-r8a7778.c | 13 ++++++------- > arch/arm/mach-shmobile/setup-r8a7779.c | 6 +++--- > arch/arm/mach-shmobile/setup-r8a7790.c | 10 +++++----- > arch/arm/mach-shmobile/setup-r8a7791.c | 8 ++++---- > arch/unicore32/kernel/puv3-core.c | 2 +- > arch/unicore32/kernel/puv3-nb0916.c | 6 +++--- > drivers/base/platform.c | 18 +++++++++++------ > drivers/char/tile-srom.c | 2 +- > drivers/mmc/host/sdhci-pltfm.c | 2 +- > drivers/scsi/hosts.c | 2 +- > include/linux/platform_device.h | 2 +- > 25 files changed, 97 insertions(+), 107 deletions(-) > > diff --git a/arch/arm/mach-bcm/board_bcm21664.c b/arch/arm/mach-bcm/board_bcm21664.c > index f0521cc..82ad568 100644 > --- a/arch/arm/mach-bcm/board_bcm21664.c > +++ b/arch/arm/mach-bcm/board_bcm21664.c > @@ -60,8 +60,7 @@ static void bcm21664_restart(enum reboot_mode mode, const char *cmd) > > static void __init bcm21664_init(void) > { > - of_platform_populate(NULL, of_default_bus_match_table, NULL, > - &platform_bus); > + of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL); > kona_l2_cache_init(); > } > > diff --git a/arch/arm/mach-bcm/board_bcm281xx.c b/arch/arm/mach-bcm/board_bcm281xx.c > index 1ac59fc..2e367bd 100644 > --- a/arch/arm/mach-bcm/board_bcm281xx.c > +++ b/arch/arm/mach-bcm/board_bcm281xx.c > @@ -58,8 +58,7 @@ static void bcm281xx_restart(enum reboot_mode mode, const char *cmd) > > static void __init bcm281xx_init(void) > { > - of_platform_populate(NULL, of_default_bus_match_table, NULL, > - &platform_bus); > + of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL); > kona_l2_cache_init(); > } > > diff --git a/arch/arm/mach-clps711x/board-edb7211.c b/arch/arm/mach-clps711x/board-edb7211.c > index f9828f8..6144fb5 100644 > --- a/arch/arm/mach-clps711x/board-edb7211.c > +++ b/arch/arm/mach-clps711x/board-edb7211.c > @@ -158,16 +158,16 @@ static void __init edb7211_init_late(void) > gpio_request_array(edb7211_gpios, ARRAY_SIZE(edb7211_gpios)); > > platform_device_register(&edb7211_flash_pdev); > - platform_device_register_data(&platform_bus, "platform-lcd", 0, > + platform_device_register_data(NULL, "platform-lcd", 0, > &edb7211_lcd_power_pdata, > sizeof(edb7211_lcd_power_pdata)); > - platform_device_register_data(&platform_bus, "generic-bl", 0, > + platform_device_register_data(NULL, "generic-bl", 0, > &edb7211_lcd_backlight_pdata, > sizeof(edb7211_lcd_backlight_pdata)); > platform_device_register_simple("video-clps711x", 0, NULL, 0); > platform_device_register_simple("cs89x0", 0, edb7211_cs8900_resource, > ARRAY_SIZE(edb7211_cs8900_resource)); > - platform_device_register_data(&platform_bus, "i2c-gpio", 0, > + platform_device_register_data(NULL, "i2c-gpio", 0, > &edb7211_i2c_pdata, > sizeof(edb7211_i2c_pdata)); > } > diff --git a/arch/arm/mach-clps711x/board-p720t.c b/arch/arm/mach-clps711x/board-p720t.c > index 0cf0e51..96bcc76 100644 > --- a/arch/arm/mach-clps711x/board-p720t.c > +++ b/arch/arm/mach-clps711x/board-p720t.c > @@ -348,14 +348,14 @@ static void __init p720t_init_late(void) > { > WARN_ON(gpio_request_array(p720t_gpios, ARRAY_SIZE(p720t_gpios))); > > - platform_device_register_data(&platform_bus, "platform-lcd", 0, > + platform_device_register_data(NULL, "platform-lcd", 0, > &p720t_lcd_power_pdata, > sizeof(p720t_lcd_power_pdata)); > - platform_device_register_data(&platform_bus, "generic-bl", 0, > + platform_device_register_data(NULL, "generic-bl", 0, > &p720t_lcd_backlight_pdata, > sizeof(p720t_lcd_backlight_pdata)); > platform_device_register_simple("video-clps711x", 0, NULL, 0); > - platform_device_register_data(&platform_bus, "leds-gpio", 0, > + platform_device_register_data(NULL, "leds-gpio", 0, > &p720t_gpio_led_pdata, > sizeof(p720t_gpio_led_pdata)); > } > diff --git a/arch/arm/mach-imx/devices/devices.c b/arch/arm/mach-imx/devices/devices.c > index 1b4366a..48c3817 100644 > --- a/arch/arm/mach-imx/devices/devices.c > +++ b/arch/arm/mach-imx/devices/devices.c > @@ -24,12 +24,12 @@ > > struct device mxc_aips_bus = { > .init_name = "mxc_aips", > - .parent = &platform_bus, > + .parent = &platform_bus.dev, > }; > > struct device mxc_ahb_bus = { > .init_name = "mxc_ahb", > - .parent = &platform_bus, > + .parent = &platform_bus.dev, > }; > > int __init mxc_device_init(void) > diff --git a/arch/arm/mach-imx/mach-mx27ads.c b/arch/arm/mach-imx/mach-mx27ads.c > index 2f834ce..eb1c347 100644 > --- a/arch/arm/mach-imx/mach-mx27ads.c > +++ b/arch/arm/mach-imx/mach-mx27ads.c > @@ -245,7 +245,7 @@ static void __init mx27ads_regulator_init(void) > vchip->set = vgpio_set; > gpiochip_add(vchip); > > - platform_device_register_data(&platform_bus, "reg-fixed-voltage", > + platform_device_register_data(NULL, "reg-fixed-voltage", > PLATFORM_DEVID_AUTO, > &mx27ads_lcd_regulator_pdata, > sizeof(mx27ads_lcd_regulator_pdata)); > diff --git a/arch/arm/mach-shmobile/board-ape6evm.c b/arch/arm/mach-shmobile/board-ape6evm.c > index fe071a9..7ab99a4 100644 > --- a/arch/arm/mach-shmobile/board-ape6evm.c > +++ b/arch/arm/mach-shmobile/board-ape6evm.c > @@ -248,29 +248,29 @@ static void __init ape6evm_add_standard_devices(void) > > regulator_register_fixed(0, dummy_supplies, ARRAY_SIZE(dummy_supplies)); > > - platform_device_register_resndata(&platform_bus, "smsc911x", -1, > + platform_device_register_resndata(NULL, "smsc911x", -1, > lan9220_res, ARRAY_SIZE(lan9220_res), > &lan9220_data, sizeof(lan9220_data)); > > regulator_register_always_on(1, "MMC0 Vcc", vcc_mmc0_consumers, > ARRAY_SIZE(vcc_mmc0_consumers), 2800000); > - platform_device_register_resndata(&platform_bus, "sh_mmcif", 0, > + platform_device_register_resndata(NULL, "sh_mmcif", 0, > mmcif0_resources, ARRAY_SIZE(mmcif0_resources), > &mmcif0_pdata, sizeof(mmcif0_pdata)); > - platform_device_register_data(&platform_bus, "reg-fixed-voltage", 2, > + platform_device_register_data(NULL, "reg-fixed-voltage", 2, > &vcc_sdhi0_info, sizeof(vcc_sdhi0_info)); > - platform_device_register_resndata(&platform_bus, "sh_mobile_sdhi", 0, > + platform_device_register_resndata(NULL, "sh_mobile_sdhi", 0, > sdhi0_resources, ARRAY_SIZE(sdhi0_resources), > &sdhi0_pdata, sizeof(sdhi0_pdata)); > regulator_register_always_on(3, "SDHI1 Vcc", vcc_sdhi1_consumers, > ARRAY_SIZE(vcc_sdhi1_consumers), 3300000); > - platform_device_register_resndata(&platform_bus, "sh_mobile_sdhi", 1, > + platform_device_register_resndata(NULL, "sh_mobile_sdhi", 1, > sdhi1_resources, ARRAY_SIZE(sdhi1_resources), > &sdhi1_pdata, sizeof(sdhi1_pdata)); > - platform_device_register_data(&platform_bus, "gpio-keys", -1, > + platform_device_register_data(NULL, "gpio-keys", -1, > &ape6evm_keys_pdata, > sizeof(ape6evm_keys_pdata)); > - platform_device_register_data(&platform_bus, "leds-gpio", -1, > + platform_device_register_data(NULL, "leds-gpio", -1, > &ape6evm_leds_pdata, > sizeof(ape6evm_leds_pdata)); > } > diff --git a/arch/arm/mach-shmobile/board-bockw.c b/arch/arm/mach-shmobile/board-bockw.c > index f444be2..3ec82a4 100644 > --- a/arch/arm/mach-shmobile/board-bockw.c > +++ b/arch/arm/mach-shmobile/board-bockw.c > @@ -177,7 +177,7 @@ static struct renesas_usbhs_platform_info usbhs_info __initdata = { > #define USB1_DEVICE "renesas_usbhs" > #define ADD_USB_FUNC_DEVICE_IF_POSSIBLE() \ > platform_device_register_resndata( \ > - &platform_bus, "renesas_usbhs", -1, \ > + NULL, "renesas_usbhs", -1, \ > usbhsf_resources, \ > ARRAY_SIZE(usbhsf_resources), \ > &usbhs_info, sizeof(struct renesas_usbhs_platform_info)) > @@ -236,7 +236,6 @@ static struct sh_eth_plat_data ether_platform_data __initdata = { > }; > > static struct platform_device_info ether_info __initdata = { > - .parent = &platform_bus, > .name = "r8a777x-ether", > .id = -1, > .res = ether_resources, > @@ -322,7 +321,6 @@ static struct resource vin##idx##_resources[] __initdata = { \ > }; \ > \ > static struct platform_device_info vin##idx##_info __initdata = { \ > - .parent = &platform_bus, \ > .name = "r8a7778-vin", \ > .id = idx, \ > .res = vin##idx##_resources, \ > @@ -621,10 +619,10 @@ static void __init bockw_init(void) > /* VIN1 has a pin conflict with Ether */ > if (!IS_ENABLED(CONFIG_SH_ETH)) > platform_device_register_full(&vin1_info); > - platform_device_register_data(&platform_bus, "soc-camera-pdrv", 0, > + platform_device_register_data(NULL, "soc-camera-pdrv", 0, > &iclink0_ml86v7667, > sizeof(iclink0_ml86v7667)); > - platform_device_register_data(&platform_bus, "soc-camera-pdrv", 1, > + platform_device_register_data(NULL, "soc-camera-pdrv", 1, > &iclink1_ml86v7667, > sizeof(iclink1_ml86v7667)); > > @@ -637,12 +635,12 @@ static void __init bockw_init(void) > r8a7778_pinmux_init(); > > platform_device_register_resndata( > - &platform_bus, "sh_mmcif", -1, > + NULL, "sh_mmcif", -1, > mmc_resources, ARRAY_SIZE(mmc_resources), > &sh_mmcif_plat, sizeof(struct sh_mmcif_plat_data)); > > platform_device_register_resndata( > - &platform_bus, "rcar_usb_phy", -1, > + NULL, "rcar_usb_phy", -1, > usb_phy_resources, > ARRAY_SIZE(usb_phy_resources), > &usb_phy_platform_data, > @@ -668,7 +666,7 @@ static void __init bockw_init(void) > iowrite16(val, fpga + IRQ0MR); > > platform_device_register_resndata( > - &platform_bus, "smsc911x", -1, > + NULL, "smsc911x", -1, > smsc911x_resources, ARRAY_SIZE(smsc911x_resources), > &smsc911x_data, sizeof(smsc911x_data)); > } > @@ -685,7 +683,7 @@ static void __init bockw_init(void) > iounmap(base); > > platform_device_register_resndata( > - &platform_bus, "sh_mobile_sdhi", 0, > + NULL, "sh_mobile_sdhi", 0, > sdhi0_resources, ARRAY_SIZE(sdhi0_resources), > &sdhi0_info, sizeof(struct sh_mobile_sdhi_info)); > } > @@ -700,7 +698,7 @@ static void __init bockw_init(void) > "ak4554-adc-dac", 1, NULL, 0); > > pdev = platform_device_register_resndata( > - &platform_bus, "rcar_sound", -1, > + NULL, "rcar_sound", -1, > rsnd_resources, ARRAY_SIZE(rsnd_resources), > &rsnd_info, sizeof(rsnd_info)); > > @@ -710,7 +708,6 @@ static void __init bockw_init(void) > > for (i = 0; i < ARRAY_SIZE(rsnd_card_info); i++) { > struct platform_device_info cardinfo = { > - .parent = &platform_bus, > .name = "asoc-simple-card", > .id = i, > .data = &rsnd_card_info[i], > diff --git a/arch/arm/mach-shmobile/board-genmai.c b/arch/arm/mach-shmobile/board-genmai.c > index c94201e..37184ff 100644 > --- a/arch/arm/mach-shmobile/board-genmai.c > +++ b/arch/arm/mach-shmobile/board-genmai.c > @@ -46,7 +46,6 @@ static const struct resource ether_resources[] __initconst = { > }; > > static const struct platform_device_info ether_info __initconst = { > - .parent = &platform_bus, > .name = "r7s72100-ether", > .id = -1, > .res = ether_resources, > @@ -76,7 +75,7 @@ static const struct rspi_plat_data rspi_pdata __initconst = { > }; > > #define r7s72100_register_rspi(idx) \ > - platform_device_register_resndata(&platform_bus, "rspi-rz", idx, \ > + platform_device_register_resndata(NULL, "rspi-rz", idx, \ > rspi##idx##_resources, \ > ARRAY_SIZE(rspi##idx##_resources), \ > &rspi_pdata, sizeof(rspi_pdata)) > @@ -118,7 +117,7 @@ R7S72100_SCIF(6, 0xe800a000, gic_iid(245)); > R7S72100_SCIF(7, 0xe800a800, gic_iid(249)); > > #define r7s72100_register_scif(index) \ > - platform_device_register_resndata(&platform_bus, "sh-sci", index, \ > + platform_device_register_resndata(NULL, "sh-sci", index, \ > scif##index##_resources, \ > ARRAY_SIZE(scif##index##_resources), \ > &scif##index##_platform_data, \ > diff --git a/arch/arm/mach-shmobile/board-koelsch.c b/arch/arm/mach-shmobile/board-koelsch.c > index c6c6889..d3aa6ae 100644 > --- a/arch/arm/mach-shmobile/board-koelsch.c > +++ b/arch/arm/mach-shmobile/board-koelsch.c > @@ -118,7 +118,6 @@ static const struct resource ether_resources[] __initconst = { > }; > > static const struct platform_device_info ether_info __initconst = { > - .parent = &platform_bus, > .name = "r8a7791-ether", > .id = -1, > .res = ether_resources, > @@ -230,7 +229,6 @@ static const struct resource sata0_resources[] __initconst = { > }; > > static const struct platform_device_info sata0_info __initconst = { > - .parent = &platform_bus, > .name = "sata-r8a7791", > .id = 0, > .res = sata0_resources, > @@ -439,13 +437,13 @@ static void __init koelsch_add_standard_devices(void) > r8a7791_pinmux_init(); > r8a7791_add_standard_devices(); > platform_device_register_full(ðer_info); > - platform_device_register_data(&platform_bus, "leds-gpio", -1, > + platform_device_register_data(NULL, "leds-gpio", -1, > &koelsch_leds_pdata, > sizeof(koelsch_leds_pdata)); > - platform_device_register_data(&platform_bus, "gpio-keys", -1, > + platform_device_register_data(NULL, "gpio-keys", -1, > &koelsch_keys_pdata, > sizeof(koelsch_keys_pdata)); > - platform_device_register_resndata(&platform_bus, "qspi", 0, > + platform_device_register_resndata(NULL, "qspi", 0, > qspi_resources, > ARRAY_SIZE(qspi_resources), > &qspi_pdata, sizeof(qspi_pdata)); > @@ -460,28 +458,28 @@ static void __init koelsch_add_standard_devices(void) > koelsch_add_i2c(4); > koelsch_add_i2c(5); > > - platform_device_register_data(&platform_bus, "reg-fixed-voltage", 0, > + platform_device_register_data(NULL, "reg-fixed-voltage", 0, > &vcc_sdhi0_info, sizeof(struct fixed_voltage_config)); > - platform_device_register_data(&platform_bus, "reg-fixed-voltage", 1, > + platform_device_register_data(NULL, "reg-fixed-voltage", 1, > &vcc_sdhi1_info, sizeof(struct fixed_voltage_config)); > - platform_device_register_data(&platform_bus, "reg-fixed-voltage", 2, > + platform_device_register_data(NULL, "reg-fixed-voltage", 2, > &vcc_sdhi2_info, sizeof(struct fixed_voltage_config)); > - platform_device_register_data(&platform_bus, "gpio-regulator", 0, > + platform_device_register_data(NULL, "gpio-regulator", 0, > &vccq_sdhi0_info, sizeof(struct gpio_regulator_config)); > - platform_device_register_data(&platform_bus, "gpio-regulator", 1, > + platform_device_register_data(NULL, "gpio-regulator", 1, > &vccq_sdhi1_info, sizeof(struct gpio_regulator_config)); > - platform_device_register_data(&platform_bus, "gpio-regulator", 2, > + platform_device_register_data(NULL, "gpio-regulator", 2, > &vccq_sdhi2_info, sizeof(struct gpio_regulator_config)); > > - platform_device_register_resndata(&platform_bus, "sh_mobile_sdhi", 0, > + platform_device_register_resndata(NULL, "sh_mobile_sdhi", 0, > sdhi0_resources, ARRAY_SIZE(sdhi0_resources), > &sdhi0_info, sizeof(struct sh_mobile_sdhi_info)); > > - platform_device_register_resndata(&platform_bus, "sh_mobile_sdhi", 1, > + platform_device_register_resndata(NULL, "sh_mobile_sdhi", 1, > sdhi1_resources, ARRAY_SIZE(sdhi1_resources), > &sdhi1_info, sizeof(struct sh_mobile_sdhi_info)); > > - platform_device_register_resndata(&platform_bus, "sh_mobile_sdhi", 2, > + platform_device_register_resndata(NULL, "sh_mobile_sdhi", 2, > sdhi2_resources, ARRAY_SIZE(sdhi2_resources), > &sdhi2_info, sizeof(struct sh_mobile_sdhi_info)); > > diff --git a/arch/arm/mach-shmobile/board-lager.c b/arch/arm/mach-shmobile/board-lager.c > index f8b1e05..d182961 100644 > --- a/arch/arm/mach-shmobile/board-lager.c > +++ b/arch/arm/mach-shmobile/board-lager.c > @@ -277,7 +277,6 @@ static const struct resource ether_resources[] __initconst = { > }; > > static const struct platform_device_info ether_info __initconst = { > - .parent = &platform_bus, > .name = "r8a7790-ether", > .id = -1, > .res = ether_resources, > @@ -354,7 +353,6 @@ static void __init lager_add_vin_device(unsigned idx, > struct rcar_vin_platform_data *pdata) > { > struct platform_device_info vin_info = { > - .parent = &platform_bus, > .name = "r8a7790-vin", > .id = idx, > .res = &vin_resources[idx * 2], > @@ -391,7 +389,7 @@ LAGER_CAMERA(1, "adv7180", 0x20, NULL, RCAR_VIN_BT656); > > static void __init lager_add_camera1_device(void) > { > - platform_device_register_data(&platform_bus, "soc-camera-pdrv", 1, > + platform_device_register_data(NULL, "soc-camera-pdrv", 1, > &cam1_link, sizeof(cam1_link)); > lager_add_vin_device(1, &vin1_pdata); > } > @@ -403,7 +401,6 @@ static const struct resource sata1_resources[] __initconst = { > }; > > static const struct platform_device_info sata1_info __initconst = { > - .parent = &platform_bus, > .name = "sata-r8a7790", > .id = 1, > .res = sata1_resources, > @@ -533,7 +530,7 @@ static struct usbhs_private usbhs_priv __initdata = { > static void __init lager_register_usbhs(void) > { > usb_bind_phy("renesas_usbhs", 0, "usb_phy_rcar_gen2"); > - platform_device_register_resndata(&platform_bus, > + platform_device_register_resndata(NULL, > "renesas_usbhs", -1, > usbhs_resources, > ARRAY_SIZE(usbhs_resources), > @@ -608,7 +605,6 @@ static struct asoc_simple_card_info rsnd_card_info = { > static void __init lager_add_rsnd_device(void) > { > struct platform_device_info cardinfo = { > - .parent = &platform_bus, > .name = "asoc-simple-card", > .id = -1, > .data = &rsnd_card_info, > @@ -620,7 +616,7 @@ static void __init lager_add_rsnd_device(void) > ARRAY_SIZE(i2c2_devices)); > > platform_device_register_resndata( > - &platform_bus, "rcar_sound", -1, > + NULL, "rcar_sound", -1, > rsnd_resources, ARRAY_SIZE(rsnd_resources), > &rsnd_info, sizeof(rsnd_info)); > > @@ -663,7 +659,6 @@ static const struct resource pci1_resources[] __initconst = { > }; > > static const struct platform_device_info pci1_info __initconst = { > - .parent = &platform_bus, > .name = "pci-rcar-gen2", > .id = 1, > .res = pci1_resources, > @@ -684,7 +679,6 @@ static const struct resource pci2_resources[] __initconst = { > }; > > static const struct platform_device_info pci2_info __initconst = { > - .parent = &platform_bus, > .name = "pci-rcar-gen2", > .id = 2, > .res = pci2_resources, > @@ -795,16 +789,16 @@ static void __init lager_add_standard_devices(void) > r8a7790_pinmux_init(); > > r8a7790_add_standard_devices(); > - platform_device_register_data(&platform_bus, "leds-gpio", -1, > + platform_device_register_data(NULL, "leds-gpio", -1, > &lager_leds_pdata, > sizeof(lager_leds_pdata)); > - platform_device_register_data(&platform_bus, "gpio-keys", -1, > + platform_device_register_data(NULL, "gpio-keys", -1, > &lager_keys_pdata, > sizeof(lager_keys_pdata)); > regulator_register_always_on(fixed_regulator_idx++, > "fixed-3.3V", fixed3v3_power_consumers, > ARRAY_SIZE(fixed3v3_power_consumers), 3300000); > - platform_device_register_resndata(&platform_bus, "sh_mmcif", 1, > + platform_device_register_resndata(NULL, "sh_mmcif", 1, > mmcif1_resources, ARRAY_SIZE(mmcif1_resources), > &mmcif1_pdata, sizeof(mmcif1_pdata)); > > @@ -812,27 +806,27 @@ static void __init lager_add_standard_devices(void) > > lager_add_du_device(); > > - platform_device_register_resndata(&platform_bus, "qspi", 0, > + platform_device_register_resndata(NULL, "qspi", 0, > qspi_resources, > ARRAY_SIZE(qspi_resources), > &qspi_pdata, sizeof(qspi_pdata)); > spi_register_board_info(spi_info, ARRAY_SIZE(spi_info)); > > - platform_device_register_data(&platform_bus, "reg-fixed-voltage", fixed_regulator_idx++, > + platform_device_register_data(NULL, "reg-fixed-voltage", fixed_regulator_idx++, > &vcc_sdhi0_info, sizeof(struct fixed_voltage_config)); > - platform_device_register_data(&platform_bus, "reg-fixed-voltage", fixed_regulator_idx++, > + platform_device_register_data(NULL, "reg-fixed-voltage", fixed_regulator_idx++, > &vcc_sdhi2_info, sizeof(struct fixed_voltage_config)); > > - platform_device_register_data(&platform_bus, "gpio-regulator", gpio_regulator_idx++, > + platform_device_register_data(NULL, "gpio-regulator", gpio_regulator_idx++, > &vccq_sdhi0_info, sizeof(struct gpio_regulator_config)); > - platform_device_register_data(&platform_bus, "gpio-regulator", gpio_regulator_idx++, > + platform_device_register_data(NULL, "gpio-regulator", gpio_regulator_idx++, > &vccq_sdhi2_info, sizeof(struct gpio_regulator_config)); > > lager_add_camera1_device(); > > platform_device_register_full(&sata1_info); > > - platform_device_register_resndata(&platform_bus, "usb_phy_rcar_gen2", > + platform_device_register_resndata(NULL, "usb_phy_rcar_gen2", > -1, usbhs_phy_resources, > ARRAY_SIZE(usbhs_phy_resources), > &usbhs_phy_pdata, > @@ -843,10 +837,10 @@ static void __init lager_add_standard_devices(void) > > lager_add_rsnd_device(); > > - platform_device_register_resndata(&platform_bus, "sh_mobile_sdhi", 0, > + platform_device_register_resndata(NULL, "sh_mobile_sdhi", 0, > sdhi0_resources, ARRAY_SIZE(sdhi0_resources), > &sdhi0_info, sizeof(struct sh_mobile_sdhi_info)); > - platform_device_register_resndata(&platform_bus, "sh_mobile_sdhi", 2, > + platform_device_register_resndata(NULL, "sh_mobile_sdhi", 2, > sdhi2_resources, ARRAY_SIZE(sdhi2_resources), > &sdhi2_info, sizeof(struct sh_mobile_sdhi_info)); > } > diff --git a/arch/arm/mach-shmobile/board-marzen.c b/arch/arm/mach-shmobile/board-marzen.c > index d832a44..6ed324c 100644 > --- a/arch/arm/mach-shmobile/board-marzen.c > +++ b/arch/arm/mach-shmobile/board-marzen.c > @@ -272,7 +272,6 @@ static struct resource vin##idx##_resources[] __initdata = { \ > }; \ > \ > static struct platform_device_info vin##idx##_info __initdata = { \ > - .parent = &platform_bus, \ > .name = "r8a7779-vin", \ > .id = idx, \ > .res = vin##idx##_resources, \ > diff --git a/arch/arm/mach-shmobile/setup-r7s72100.c b/arch/arm/mach-shmobile/setup-r7s72100.c > index 412e179..3885a59 100644 > --- a/arch/arm/mach-shmobile/setup-r7s72100.c > +++ b/arch/arm/mach-shmobile/setup-r7s72100.c > @@ -33,7 +33,7 @@ static struct resource mtu2_resources[] __initdata = { > }; > > #define r7s72100_register_mtu2() \ > - platform_device_register_resndata(&platform_bus, "sh-mtu2", \ > + platform_device_register_resndata(NULL, "sh-mtu2", \ > -1, mtu2_resources, \ > ARRAY_SIZE(mtu2_resources), \ > NULL, 0) > diff --git a/arch/arm/mach-shmobile/setup-r8a73a4.c b/arch/arm/mach-shmobile/setup-r8a73a4.c > index 9333770..aaaaf6e 100644 > --- a/arch/arm/mach-shmobile/setup-r8a73a4.c > +++ b/arch/arm/mach-shmobile/setup-r8a73a4.c > @@ -68,7 +68,7 @@ R8A73A4_SCIFB(4, 0xe6ce0000, gic_spi(150)); /* SCIFB2 */ > R8A73A4_SCIFB(5, 0xe6cf0000, gic_spi(151)); /* SCIFB3 */ > > #define r8a73a4_register_scif(index) \ > - platform_device_register_resndata(&platform_bus, "sh-sci", index, \ > + platform_device_register_resndata(NULL, "sh-sci", index, \ > scif##index##_resources, \ > ARRAY_SIZE(scif##index##_resources), \ > &scif##index##_platform_data, \ > @@ -149,7 +149,7 @@ static const struct resource irqc1_resources[] = { > }; > > #define r8a73a4_register_irqc(idx) \ > - platform_device_register_resndata(&platform_bus, "renesas_irqc", \ > + platform_device_register_resndata(NULL, "renesas_irqc", \ > idx, irqc##idx##_resources, \ > ARRAY_SIZE(irqc##idx##_resources), \ > &irqc##idx##_data, \ > @@ -179,7 +179,7 @@ static struct resource cmt1_resources[] = { > }; > > #define r8a7790_register_cmt(idx) \ > - platform_device_register_resndata(&platform_bus, "sh-cmt-48-gen2", \ > + platform_device_register_resndata(NULL, "sh-cmt-48-gen2", \ > idx, cmt##idx##_resources, \ > ARRAY_SIZE(cmt##idx##_resources), \ > &cmt##idx##_platform_data, \ > @@ -280,7 +280,7 @@ static struct resource dma_resources[] = { > }; > > #define r8a73a4_register_dmac() \ > - platform_device_register_resndata(&platform_bus, "sh-dma-engine", 0, \ > + platform_device_register_resndata(NULL, "sh-dma-engine", 0, \ > dma_resources, ARRAY_SIZE(dma_resources), \ > &dma_pdata, sizeof(dma_pdata)) > > diff --git a/arch/arm/mach-shmobile/setup-r8a7778.c b/arch/arm/mach-shmobile/setup-r8a7778.c > index d311ef9..5de7b33 100644 > --- a/arch/arm/mach-shmobile/setup-r8a7778.c > +++ b/arch/arm/mach-shmobile/setup-r8a7778.c > @@ -64,7 +64,7 @@ R8A7778_SCIF(4, 0xffe44000, gic_iid(0x6a)); > R8A7778_SCIF(5, 0xffe45000, gic_iid(0x6b)); > > #define r8a7778_register_scif(index) \ > - platform_device_register_resndata(&platform_bus, "sh-sci", index, \ > + platform_device_register_resndata(NULL, "sh-sci", index, \ > scif##index##_resources, \ > ARRAY_SIZE(scif##index##_resources), \ > &scif##index##_platform_data, \ > @@ -84,7 +84,7 @@ static struct resource sh_tmu0_resources[] = { > > #define r8a7778_register_tmu(idx) \ > platform_device_register_resndata( \ > - &platform_bus, "sh-tmu", idx, \ > + NULL, "sh-tmu", idx, \ > sh_tmu##idx##_resources, \ > ARRAY_SIZE(sh_tmu##idx##_resources), \ > &sh_tmu##idx##_platform_data, \ > @@ -173,7 +173,6 @@ static struct resource ohci_resources[] __initdata = { > > #define USB_PLATFORM_INFO(hci) \ > static struct platform_device_info hci##_info __initdata = { \ > - .parent = &platform_bus, \ > .name = #hci "-platform", \ > .id = -1, \ > .res = hci##_resources, \ > @@ -212,7 +211,7 @@ R8A7778_GPIO(4); > > #define r8a7778_register_gpio(idx) \ > platform_device_register_resndata( \ > - &platform_bus, "gpio_rcar", idx, \ > + NULL, "gpio_rcar", idx, \ > r8a7778_gpio##idx##_resources, \ > ARRAY_SIZE(r8a7778_gpio##idx##_resources), \ > &r8a7778_gpio##idx##_platform_data, \ > @@ -496,8 +495,8 @@ static struct resource hpb_dmae_resources[] __initdata = { > > static void __init r8a7778_register_hpb_dmae(void) > { > - platform_device_register_resndata(&platform_bus, "hpb-dma-engine", -1, > - hpb_dmae_resources, > + platform_device_register_resndata(NULL, "hpb-dma-engine", > + -1, hpb_dmae_resources, > ARRAY_SIZE(hpb_dmae_resources), > &dma_platform_data, > sizeof(dma_platform_data)); > @@ -565,7 +564,7 @@ void __init r8a7778_init_irq_extpin(int irlm) > r8a7778_init_irq_extpin_dt(irlm); > if (irlm) > platform_device_register_resndata( > - &platform_bus, "renesas_intc_irqpin", -1, > + NULL, "renesas_intc_irqpin", -1, > irqpin_resources, ARRAY_SIZE(irqpin_resources), > &irqpin_platform_data, sizeof(irqpin_platform_data)); > } > diff --git a/arch/arm/mach-shmobile/setup-r8a7779.c b/arch/arm/mach-shmobile/setup-r8a7779.c > index aba4ed6..9c79182 100644 > --- a/arch/arm/mach-shmobile/setup-r8a7779.c > +++ b/arch/arm/mach-shmobile/setup-r8a7779.c > @@ -123,7 +123,7 @@ void __init r8a7779_init_irq_extpin(int irlm) > r8a7779_init_irq_extpin_dt(irlm); > if (irlm) > platform_device_register_resndata( > - &platform_bus, "renesas_intc_irqpin", -1, > + NULL, "renesas_intc_irqpin", -1, > irqpin0_resources, ARRAY_SIZE(irqpin0_resources), > &irqpin0_platform_data, sizeof(irqpin0_platform_data)); > } > @@ -632,8 +632,8 @@ static struct resource hpb_dmae_resources[] __initdata = { > > static void __init r8a7779_register_hpb_dmae(void) > { > - platform_device_register_resndata(&platform_bus, "hpb-dma-engine", -1, > - hpb_dmae_resources, > + platform_device_register_resndata(NULL, "hpb-dma-engine", > + -1, hpb_dmae_resources, > ARRAY_SIZE(hpb_dmae_resources), > &dma_platform_data, > sizeof(dma_platform_data)); > diff --git a/arch/arm/mach-shmobile/setup-r8a7790.c b/arch/arm/mach-shmobile/setup-r8a7790.c > index 6bd08b1..10e6768 100644 > --- a/arch/arm/mach-shmobile/setup-r8a7790.c > +++ b/arch/arm/mach-shmobile/setup-r8a7790.c > @@ -113,7 +113,7 @@ static struct resource r8a7790_audio_dmac_resources[] = { > > #define r8a7790_register_audio_dmac(id) \ > platform_device_register_resndata( \ > - &platform_bus, "sh-dma-engine", id, \ > + NULL, "sh-dma-engine", id, \ > &r8a7790_audio_dmac_resources[id * 3], 3, \ > &r8a7790_audio_dmac_platform_data, \ > sizeof(r8a7790_audio_dmac_platform_data)) > @@ -149,7 +149,7 @@ R8A7790_GPIO(4); > R8A7790_GPIO(5); > > #define r8a7790_register_gpio(idx) \ > - platform_device_register_resndata(&platform_bus, "gpio_rcar", idx, \ > + platform_device_register_resndata(NULL, "gpio_rcar", idx, \ > r8a7790_gpio##idx##_resources, \ > ARRAY_SIZE(r8a7790_gpio##idx##_resources), \ > &r8a7790_gpio##idx##_platform_data, \ > @@ -227,7 +227,7 @@ R8A7790_HSCIF(8, 0xe62c0000, gic_spi(154)); /* HSCIF0 */ > R8A7790_HSCIF(9, 0xe62c8000, gic_spi(155)); /* HSCIF1 */ > > #define r8a7790_register_scif(index) \ > - platform_device_register_resndata(&platform_bus, "sh-sci", index, \ > + platform_device_register_resndata(NULL, "sh-sci", index, \ > scif##index##_resources, \ > ARRAY_SIZE(scif##index##_resources), \ > &scif##index##_platform_data, \ > @@ -246,7 +246,7 @@ static const struct resource irqc0_resources[] __initconst = { > }; > > #define r8a7790_register_irqc(idx) \ > - platform_device_register_resndata(&platform_bus, "renesas_irqc", \ > + platform_device_register_resndata(NULL, "renesas_irqc", \ > idx, irqc##idx##_resources, \ > ARRAY_SIZE(irqc##idx##_resources), \ > &irqc##idx##_data, \ > @@ -273,7 +273,7 @@ static struct resource cmt0_resources[] = { > }; > > #define r8a7790_register_cmt(idx) \ > - platform_device_register_resndata(&platform_bus, "sh-cmt-48-gen2", \ > + platform_device_register_resndata(NULL, "sh-cmt-48-gen2", \ > idx, cmt##idx##_resources, \ > ARRAY_SIZE(cmt##idx##_resources), \ > &cmt##idx##_platform_data, \ > diff --git a/arch/arm/mach-shmobile/setup-r8a7791.c b/arch/arm/mach-shmobile/setup-r8a7791.c > index 04a96dd..fd54437 100644 > --- a/arch/arm/mach-shmobile/setup-r8a7791.c > +++ b/arch/arm/mach-shmobile/setup-r8a7791.c > @@ -65,7 +65,7 @@ R8A7791_GPIO(6, 0xe6055400, 32); > R8A7791_GPIO(7, 0xe6055800, 26); > > #define r8a7791_register_gpio(idx) \ > - platform_device_register_resndata(&platform_bus, "gpio_rcar", idx, \ > + platform_device_register_resndata(NULL, "gpio_rcar", idx, \ > r8a7791_gpio##idx##_resources, \ > ARRAY_SIZE(r8a7791_gpio##idx##_resources), \ > &r8a7791_gpio##idx##_platform_data, \ > @@ -122,7 +122,7 @@ R8A7791_SCIFA(13, 0xe6c78000, gic_spi(30)); /* SCIFA4 */ > R8A7791_SCIFA(14, 0xe6c80000, gic_spi(31)); /* SCIFA5 */ > > #define r8a7791_register_scif(index) \ > - platform_device_register_resndata(&platform_bus, "sh-sci", index, \ > + platform_device_register_resndata(NULL, "sh-sci", index, \ > scif##index##_resources, \ > ARRAY_SIZE(scif##index##_resources), \ > &scif##index##_platform_data, \ > @@ -138,7 +138,7 @@ static struct resource cmt0_resources[] = { > }; > > #define r8a7791_register_cmt(idx) \ > - platform_device_register_resndata(&platform_bus, "sh-cmt-48-gen2", \ > + platform_device_register_resndata(NULL, "sh-cmt-48-gen2", \ > idx, cmt##idx##_resources, \ > ARRAY_SIZE(cmt##idx##_resources), \ > &cmt##idx##_platform_data, \ > @@ -163,7 +163,7 @@ static struct resource irqc0_resources[] = { > }; > > #define r8a7791_register_irqc(idx) \ > - platform_device_register_resndata(&platform_bus, "renesas_irqc", \ > + platform_device_register_resndata(NULL, "renesas_irqc", \ > idx, irqc##idx##_resources, \ > ARRAY_SIZE(irqc##idx##_resources), \ > &irqc##idx##_data, \ > diff --git a/arch/unicore32/kernel/puv3-core.c b/arch/unicore32/kernel/puv3-core.c > index 254adee..438dd2e 100644 > --- a/arch/unicore32/kernel/puv3-core.c > +++ b/arch/unicore32/kernel/puv3-core.c > @@ -272,7 +272,7 @@ void __init puv3_core_init(void) > platform_device_register_simple("PKUnity-v3-UART", 1, > puv3_uart1_resources, ARRAY_SIZE(puv3_uart1_resources)); > platform_device_register_simple("PKUnity-v3-AC97", -1, NULL, 0); > - platform_device_register_resndata(&platform_bus, "musb_hdrc", -1, > + platform_device_register_resndata(NULL, "musb_hdrc", -1, > puv3_usb_resources, ARRAY_SIZE(puv3_usb_resources), > &puv3_usb_plat, sizeof(puv3_usb_plat)); > } > diff --git a/arch/unicore32/kernel/puv3-nb0916.c b/arch/unicore32/kernel/puv3-nb0916.c > index 0c6618e..46ebfdc 100644 > --- a/arch/unicore32/kernel/puv3-nb0916.c > +++ b/arch/unicore32/kernel/puv3-nb0916.c > @@ -112,13 +112,13 @@ int __init mach_nb0916_init(void) > platform_device_register_simple("PKUnity-v3-I2C", -1, > puv3_i2c_resources, ARRAY_SIZE(puv3_i2c_resources)); > > - platform_device_register_data(&platform_bus, "pwm-backlight", -1, > + platform_device_register_data(NULL, "pwm-backlight", -1, > &nb0916_backlight_data, sizeof(nb0916_backlight_data)); > > - platform_device_register_data(&platform_bus, "gpio-keys", -1, > + platform_device_register_data(NULL, "gpio-keys", -1, > &nb0916_gpio_button_data, sizeof(nb0916_gpio_button_data)); > > - platform_device_register_resndata(&platform_bus, "physmap-flash", -1, > + platform_device_register_resndata(NULL, "physmap-flash", -1, > &physmap_flash_resource, 1, > &physmap_flash_data, sizeof(physmap_flash_data)); > > diff --git a/drivers/base/platform.c b/drivers/base/platform.c > index eee48c4..f272603 100644 > --- a/drivers/base/platform.c > +++ b/drivers/base/platform.c > @@ -30,8 +30,8 @@ > /* For automatically allocated device IDs */ > static DEFINE_IDA(platform_devid_ida); > > -struct device platform_bus = { > - .init_name = "platform", > +struct platform_device platform_bus = { > + .name = "platform", > }; > EXPORT_SYMBOL_GPL(platform_bus); > > @@ -300,7 +300,7 @@ int platform_device_add(struct platform_device *pdev) > return -EINVAL; > > if (!pdev->dev.parent) > - pdev->dev.parent = &platform_bus; > + pdev->dev.parent = &platform_bus.dev; > > pdev->dev.bus = &platform_bus_type; > > @@ -946,12 +946,18 @@ int __init platform_bus_init(void) > > early_platform_cleanup(); > > - error = device_register(&platform_bus); > + dev_set_name(&platform_bus.dev, "%s", platform_bus.name); > + error = device_register(&platform_bus.dev); > if (error) > return error; > error = bus_register(&platform_bus_type); > - if (error) > - device_unregister(&platform_bus); > + if (!error) { > + platform_bus.dev.of_node = of_allnodes; This breaks all non-OF platforms: drivers/base/platform.c: In function 'platform_bus_init': drivers/base/platform.c:955:30: error: 'of_allnodes' undeclared (first use in this function) platform_bus.dev.of_node = of_allnodes; -Olof ^ permalink raw reply [flat|nested] 48+ messages in thread
* [PATCH v3] platform: Make platform_bus device a platform device 2014-07-22 19:46 ` Olof Johansson @ 2014-07-23 14:26 ` Pawel Moll 0 siblings, 0 replies; 48+ messages in thread From: Pawel Moll @ 2014-07-23 14:26 UTC (permalink / raw) To: linux-arm-kernel On Tue, 2014-07-22 at 20:46 +0100, Olof Johansson wrote: > > @@ -946,12 +946,18 @@ int __init platform_bus_init(void) > > > > early_platform_cleanup(); > > > > - error = device_register(&platform_bus); > > + dev_set_name(&platform_bus.dev, "%s", platform_bus.name); > > + error = device_register(&platform_bus.dev); > > if (error) > > return error; > > error = bus_register(&platform_bus_type); > > - if (error) > > - device_unregister(&platform_bus); > > + if (!error) { > > + platform_bus.dev.of_node = of_allnodes; > > This breaks all non-OF platforms: > > drivers/base/platform.c: In function 'platform_bus_init': > drivers/base/platform.c:955:30: error: 'of_allnodes' undeclared (first > use in this function) > platform_bus.dev.of_node = of_allnodes; Right, of course, my bad. I can't see any other way of getting the tree root, so an #ifdef it will be... Thanks for pointing this out! Pawe? ^ permalink raw reply [flat|nested] 48+ messages in thread
* [PATCH v3] platform: Make platform_bus device a platform device 2014-07-22 17:55 ` [PATCH v3] " Pawel Moll 2014-07-22 18:01 ` Pawel Moll 2014-07-22 19:46 ` Olof Johansson @ 2014-07-22 22:16 ` Greg Kroah-Hartman 2014-07-23 14:27 ` Pawel Moll 2 siblings, 1 reply; 48+ messages in thread From: Greg Kroah-Hartman @ 2014-07-22 22:16 UTC (permalink / raw) To: linux-arm-kernel On Tue, Jul 22, 2014 at 06:55:19PM +0100, Pawel Moll wrote: > ... describing the root of the device tree, so one can write > a platform driver initializing the platform. > > There has been a lot of references to platform_bus device where > it didn't make any sense, because simply using NULL as a parent > will make the device be adopted by the top level anyway. > > Signed-off-by: Pawel Moll <pawel.moll@arm.com> > --- > Changes since v2: > > * replaced references to platform_bus.dev with NULL > in places where it shouldn't make any difference How about split this up with just the "change to NULL" changes as one patch, and the rest as a second one? thanks, greg k-h ^ permalink raw reply [flat|nested] 48+ messages in thread
* [PATCH v3] platform: Make platform_bus device a platform device 2014-07-22 22:16 ` Greg Kroah-Hartman @ 2014-07-23 14:27 ` Pawel Moll 0 siblings, 0 replies; 48+ messages in thread From: Pawel Moll @ 2014-07-23 14:27 UTC (permalink / raw) To: linux-arm-kernel On Tue, 2014-07-22 at 23:16 +0100, Greg Kroah-Hartman wrote: > On Tue, Jul 22, 2014 at 06:55:19PM +0100, Pawel Moll wrote: > > ... describing the root of the device tree, so one can write > > a platform driver initializing the platform. > > > > There has been a lot of references to platform_bus device where > > it didn't make any sense, because simply using NULL as a parent > > will make the device be adopted by the top level anyway. > > > > Signed-off-by: Pawel Moll <pawel.moll@arm.com> > > --- > > Changes since v2: > > > > * replaced references to platform_bus.dev with NULL > > in places where it shouldn't make any difference > > How about split this up with just the "change to NULL" changes as one > patch, and the rest as a second one? Yes, was about to do exactly this. Pawel ^ permalink raw reply [flat|nested] 48+ messages in thread
* [GIT PULL 2/3] ARM: tegra: move fuse code out of arch/arm 2014-07-21 16:46 ` Olof Johansson 2014-07-21 17:00 ` [PATCH] platform: Make platform_bus device a platform device Pawel Moll @ 2014-07-22 10:27 ` Catalin Marinas 2014-07-22 16:27 ` Stephen Warren 1 sibling, 1 reply; 48+ messages in thread From: Catalin Marinas @ 2014-07-22 10:27 UTC (permalink / raw) To: linux-arm-kernel On Mon, Jul 21, 2014 at 05:46:02PM +0100, Olof Johansson wrote: > On Mon, Jul 21, 2014 at 9:38 AM, Stephen Warren <swarren@wwwdotorg.org> wrote: > > On 07/21/2014 09:54 AM, Catalin Marinas wrote: > >> We have a similar issue with arm64 vexpress (well, just on the model) > >> where vexpress_sysreg_init() is a core_initcall (should be fine as > >> arch_initcall) as it needs to be done before of_platform_populate(). > >> Pawel on cc should know more of the history here. > >> > >> I recall there were also some discussions about a SoC driver model which > >> hangs off the top compatible string in the DT (e.g. "arm,vexpress") and > >> allow (minimal) code to be run slightly earlier, though still not > >> earlier than arch_initcall. > > > > I guess that would work out OK; if we force the driver that binds to a > > top-level compatible value of "nvidia,tegraNNN" to probe first, and it > > then calls out to all the low-level init code in a sane order, that > > would solve the problem. I'm not sure that's any better than having a > > machine descriptor with an "init" function though; wrapping all this in > > a driver just seems like overhead, but it would work out OK. > > This is exactly the same as having a machine descriptor, but the > arch/arm64 maintainers don't have to look at it so they don't think it > is one. > > So now we need to find a place for machine descriptors somewhere under > drivers/* too. Sigh. Agreed, this is nothing but overhead and > overabstraction. You are missing the point. It's not the machine descriptor (or mach-* directories) I want to hide but rather the need for early SoC specific initialisation. Always providing a machine descriptor with hooks for early SoC initialisation does not provide any incentive for people to think properly about what's early hardware configuration (usually done by firmware), what's actually needed for CPU booting (SoC-independent with a secondary booting protocol selectable from a small set) and how the rest of the SoC fits with the Linux device model. It's also aimed at pushing back on hardware people who think they can mess up, for example, a GIC implementation because the rest is just software and you can always add #ifdefs. On 32-bit ARM this was not always possible (non-standard essential peripherals like IRQ controller, timers) but with arm64 we have the things needed to be able to boot an SoC to arch_initcall level without any early hooks. I agree that on occasion we may need some early SoC code just because of some (bad) hardware design or simply to work around firmware/hardware bugs (and Pawel's patch is a nice approach). But this should definitely not be the norm and I disagree with moving entire arch/arm/mach-* code to drivers/soc just because one can't decide where early SoC initialisation belongs to. Also the legacy firmware argument doesn't hold for ARMv8/arm64 since the CPU now starts at EL3 in AArch64 mode and you need code there before Linux is invoked (at EL2 or EL1). In the Tegra fuse case, it's not actually some hardware configuration that needs to be set up early but rather a driver dependency initialisation which is not (cannot be) handled by the DT. This is not that different from the vexpress sysregs mfd where we worked around using an initcall. It's not ideal, I would prefer something simpler like sibling DT node sorting during unflattening (or maybe addressing issues with deferred probing if there are any) rather than working around it using machine_desc. -- Catalin ^ permalink raw reply [flat|nested] 48+ messages in thread
* [GIT PULL 2/3] ARM: tegra: move fuse code out of arch/arm 2014-07-22 10:27 ` [GIT PULL 2/3] ARM: tegra: move fuse code out of arch/arm Catalin Marinas @ 2014-07-22 16:27 ` Stephen Warren 2014-07-22 16:54 ` Catalin Marinas 0 siblings, 1 reply; 48+ messages in thread From: Stephen Warren @ 2014-07-22 16:27 UTC (permalink / raw) To: linux-arm-kernel On 07/22/2014 04:27 AM, Catalin Marinas wrote: ... > ...It's also aimed at > pushing back on hardware people who think they can mess up, for example, > a GIC implementation because the rest is just software and you can > always add #ifdefs. I'm very concerned about this statement. Yes, it would be nice if all HW was sanely designed, but it's not always. The time to push back on bad HW design is during IP licensing agreements or HW design reviews, not upstreaming. Any pushback during SW upstreaming simply serves to make it difficult for the SW people doing the upstreaming. It has zero impact on the current HW design (it's already shipped). It probably has zero impact on the next N revisions of the HW (they're already baked). It's possible it has zero-to-minimal impact on any future HW (end-user product requirements are what matter most). ^ permalink raw reply [flat|nested] 48+ messages in thread
* [GIT PULL 2/3] ARM: tegra: move fuse code out of arch/arm 2014-07-22 16:27 ` Stephen Warren @ 2014-07-22 16:54 ` Catalin Marinas 0 siblings, 0 replies; 48+ messages in thread From: Catalin Marinas @ 2014-07-22 16:54 UTC (permalink / raw) To: linux-arm-kernel On Tue, Jul 22, 2014 at 05:27:25PM +0100, Stephen Warren wrote: > On 07/22/2014 04:27 AM, Catalin Marinas wrote: > ... > > ...It's also aimed at > > pushing back on hardware people who think they can mess up, for example, > > a GIC implementation because the rest is just software and you can > > always add #ifdefs. > > I'm very concerned about this statement. > > Yes, it would be nice if all HW was sanely designed, but it's not > always. The time to push back on bad HW design is during IP licensing > agreements or HW design reviews, not upstreaming. I agree about the HW design reviews. But I suspect some software people in such companies, concerned with upstreaming Linux support, are allowed to give feedback. And the feedback could be something like (just an example) "if we use a standard GIC and the architected timer, sane (!PL310-like) system caches, we get the benefit of no additional upstream work, better virtualisation support etc". I hope someone in the HW team would take such feedback into account rather than assume that software and upstreaming comes for free. Of course, we've never rejected Linux upstreaming because of the hardware design (well, as long as Linux could reliably run on it) and I don't plan to do this in the future, but just show that there are clear benefits in doing something in a more standardised way (e.g. SBSA for servers). Even though ARM licenses the architecture, there is no way to enforce a HW design as part of the agreement (or risk not licensing the IP at all). But there is effort to standardise things like SBSA, Trusted Firmware. > Any pushback during SW upstreaming simply serves to make it difficult > for the SW people doing the upstreaming. It has zero impact on the > current HW design (it's already shipped). It probably has zero impact on > the next N revisions of the HW (they're already baked). It's possible it > has zero-to-minimal impact on any future HW (end-user product > requirements are what matter most). I agree that pushing back during SW upstreaming is very late. But I hope to raise the awareness earlier for ARMv8 hardware. -- Catalin ^ permalink raw reply [flat|nested] 48+ messages in thread
* [GIT PULL 2/3] ARM: tegra: move fuse code out of arch/arm 2014-07-21 16:38 ` Stephen Warren 2014-07-21 16:46 ` Olof Johansson @ 2014-07-22 11:26 ` Catalin Marinas 2014-07-22 16:22 ` Stephen Warren 1 sibling, 1 reply; 48+ messages in thread From: Catalin Marinas @ 2014-07-22 11:26 UTC (permalink / raw) To: linux-arm-kernel On Mon, Jul 21, 2014 at 05:38:25PM +0100, Stephen Warren wrote: > On 07/21/2014 09:54 AM, Catalin Marinas wrote: > > On arm64, I really want to get away from any SoC specific early > > initcall. One of the main reason is for things like SCU, interconnects, > > system cache configurations (even certain clocks) to be enabled in > > firmware before Linux starts (it's an education process but that's a way > > for example to prevent people sending patches to enable SoC coherency > > because they haven't thought about it before upstreaming). > > > > It would be nice to be able to initialise SoC stuff at device_initcall() > > level (and even keep such code as modules in initramfs) but one of the > > problems we have is dependency on clocks (and the clock model which > > doesn't follow the device/driver model). The of_platform_populate() is > > called at arch_initcall_sync (after arch_initcall to still allow some > > SoC code, if needed, to run at arch_initcall). > > The main thing I want to avoid is a ton of separate drivers that all > rely on each-other getting resolved by deferred probe. While that might > work out, it seems pointless to make the kernel try and probe a bunch of > stuff just to have it fail and get repeated, when we know exactly which > order everything should get initialized in. So of_platform_populate() is called at arch_initcall_sync() level on arm64. This allows at least two levels of probing separation before (e.g. drivers registered as arch_initcall) and after (device_initcall). If you register a driver earlier than arch_initcall_sync (see for example vexpress_osc_init), it will get probed when the platform devices are populated. Any later device_initcalls will get probed when the corresponding drivers are registered. If you need ordering between device_initcalls, I would recommend deferred probing. The tricky part is if you need more drivers to be initialised at arch_initcall_sync() in a specific order. Here it looks like the node ordering in DT has an effect on probing. I don't say the DT should list them in the order they should be probed but maybe we can improve the model and do some sorting during unflattening (as I suggested in my reply to Olof). In the meantime, for vexpress we worked around it by explicitly checking the compatible node during a pre-arch_initcall. > Another issue is that we have SoCs which only differ in the CPU. Do you mean ARMv7 vs ARMv8 CPUs? > I want > the code to work identically on both SoCs so the CPU has limited affect > on the low-level IO code. If we're going to enforce a "no machine > descriptors" rule on arch/arm64, I think we should do the same thing in > arch/arm for consistency. We've done this with vexpress thanks to Pawel. As he said, the difficult part was converting the existing code to the Linux device model. The 32-bit v2m_dt_init() function simply calls of_platform_populate(). If you don't have a machine_desc at all, this would be the default (see customize_machine()). If you use PSCI, there is no need for SoC specific smp_ops either. So you basically get the same code base with no additional arch/arm/mach-* machine_desc. > > We have a similar issue with arm64 vexpress (well, just on the model) > > where vexpress_sysreg_init() is a core_initcall (should be fine as > > arch_initcall) as it needs to be done before of_platform_populate(). > > Pawel on cc should know more of the history here. > > > > I recall there were also some discussions about a SoC driver model which > > hangs off the top compatible string in the DT (e.g. "arm,vexpress") and > > allow (minimal) code to be run slightly earlier, though still not > > earlier than arch_initcall. > > I guess that would work out OK; if we force the driver that binds to a > top-level compatible value of "nvidia,tegraNNN" to probe first, and it > then calls out to all the low-level init code in a sane order, that > would solve the problem. I'm not sure that's any better than having a > machine descriptor with an "init" function though; wrapping all this in > a driver just seems like overhead, but it would work out OK. Looking at the tegra_init_early(), I think for arm64 as pre-arch_initcall_sync you would only need: tegra_init_fuse(); tegra_powergate_init(); (I'm not sure about trusted foundations but that's a 32-bit only project for the time being) >From tegra_dt_init() you need clocks but isn't CLK_OF_DECLARE enough? You also have PMC code and I'm not familiar with your implementation. A lot of the functionality could be moved to PSCI-capable firmware. -- Catalin ^ permalink raw reply [flat|nested] 48+ messages in thread
* [GIT PULL 2/3] ARM: tegra: move fuse code out of arch/arm 2014-07-22 11:26 ` Catalin Marinas @ 2014-07-22 16:22 ` Stephen Warren 2014-07-22 17:04 ` Catalin Marinas 0 siblings, 1 reply; 48+ messages in thread From: Stephen Warren @ 2014-07-22 16:22 UTC (permalink / raw) To: linux-arm-kernel On 07/22/2014 05:26 AM, Catalin Marinas wrote: > On Mon, Jul 21, 2014 at 05:38:25PM +0100, Stephen Warren wrote: >> On 07/21/2014 09:54 AM, Catalin Marinas wrote: >>> On arm64, I really want to get away from any SoC specific early >>> initcall. One of the main reason is for things like SCU, interconnects, >>> system cache configurations (even certain clocks) to be enabled in >>> firmware before Linux starts (it's an education process but that's a way >>> for example to prevent people sending patches to enable SoC coherency >>> because they haven't thought about it before upstreaming). >>> >>> It would be nice to be able to initialise SoC stuff at device_initcall() >>> level (and even keep such code as modules in initramfs) but one of the >>> problems we have is dependency on clocks (and the clock model which >>> doesn't follow the device/driver model). The of_platform_populate() is >>> called at arch_initcall_sync (after arch_initcall to still allow some >>> SoC code, if needed, to run at arch_initcall). >> >> The main thing I want to avoid is a ton of separate drivers that all >> rely on each-other getting resolved by deferred probe. While that might >> work out, it seems pointless to make the kernel try and probe a bunch of >> stuff just to have it fail and get repeated, when we know exactly which >> order everything should get initialized in. > > So of_platform_populate() is called at arch_initcall_sync() level on > arm64. This allows at least two levels of probing separation before > (e.g. drivers registered as arch_initcall) and after (device_initcall). > If you register a driver earlier than arch_initcall_sync (see for > example vexpress_osc_init), it will get probed when the platform devices > are populated. Any later device_initcalls will get probed when the > corresponding drivers are registered. If you need ordering between > device_initcalls, I would recommend deferred probing. > > The tricky part is if you need more drivers to be initialised at > arch_initcall_sync() in a specific order. I believe relying on initcall ordering, even in the case where there are enough initcall levels to achieve a particular SoC's needs, is completely and utterly the wrong way to go. Or at least, that's what the mantra has been for arch/arm for the last few years. There's been plenty of active work to get away from initcalls. Why should arch/arm64 be any different? Some consistency of maintainer viewpoints would be nice. (Note that I'm talking here about lots of separate initcalls that only work in the right order due to manually assigning them initcall levels that happen to work in the right order. Having a single initcall function that explicitly calls all other initialization functions in the right order is entirely different) Disadvantages of using initcalls are: * Not enough levels, so it's not generic/scalable. * If you need to re-order things, you need to change the initcall level of a bunch of stuff before/after it. This isn't scalable. * It's hard to track them all down. Admittedly grep works, but that's a lot more painful than just reading a function that calls other functions explicitly. * Each initcall has to determine if it's running on the correct HW or not, rather than doing it once in a single top-level initcall, or in a hook that only gets called at the right time. ... >> Another issue is that we have SoCs which only differ in the CPU. > > Do you mean ARMv7 vs ARMv8 CPUs? Yes. ^ permalink raw reply [flat|nested] 48+ messages in thread
* [GIT PULL 2/3] ARM: tegra: move fuse code out of arch/arm 2014-07-22 16:22 ` Stephen Warren @ 2014-07-22 17:04 ` Catalin Marinas 0 siblings, 0 replies; 48+ messages in thread From: Catalin Marinas @ 2014-07-22 17:04 UTC (permalink / raw) To: linux-arm-kernel On Tue, Jul 22, 2014 at 05:22:09PM +0100, Stephen Warren wrote: > On 07/22/2014 05:26 AM, Catalin Marinas wrote: > > On Mon, Jul 21, 2014 at 05:38:25PM +0100, Stephen Warren wrote: > >> On 07/21/2014 09:54 AM, Catalin Marinas wrote: > >>> On arm64, I really want to get away from any SoC specific early > >>> initcall. One of the main reason is for things like SCU, interconnects, > >>> system cache configurations (even certain clocks) to be enabled in > >>> firmware before Linux starts (it's an education process but that's a way > >>> for example to prevent people sending patches to enable SoC coherency > >>> because they haven't thought about it before upstreaming). > >>> > >>> It would be nice to be able to initialise SoC stuff at device_initcall() > >>> level (and even keep such code as modules in initramfs) but one of the > >>> problems we have is dependency on clocks (and the clock model which > >>> doesn't follow the device/driver model). The of_platform_populate() is > >>> called at arch_initcall_sync (after arch_initcall to still allow some > >>> SoC code, if needed, to run at arch_initcall). > >> > >> The main thing I want to avoid is a ton of separate drivers that all > >> rely on each-other getting resolved by deferred probe. While that might > >> work out, it seems pointless to make the kernel try and probe a bunch of > >> stuff just to have it fail and get repeated, when we know exactly which > >> order everything should get initialized in. > > > > So of_platform_populate() is called at arch_initcall_sync() level on > > arm64. This allows at least two levels of probing separation before > > (e.g. drivers registered as arch_initcall) and after (device_initcall). > > If you register a driver earlier than arch_initcall_sync (see for > > example vexpress_osc_init), it will get probed when the platform devices > > are populated. Any later device_initcalls will get probed when the > > corresponding drivers are registered. If you need ordering between > > device_initcalls, I would recommend deferred probing. > > > > The tricky part is if you need more drivers to be initialised at > > arch_initcall_sync() in a specific order. > > I believe relying on initcall ordering, even in the case where there are > enough initcall levels to achieve a particular SoC's needs, is > completely and utterly the wrong way to go. I don't like it either and I agree that there may not be enough initcalls. But I'm ok with using two levels like arch_initcall() for something like fuse and device_initcall() for the rest. If that's not enough (I haven't looked in detail at Tegra), with Pawel's patch you can get a SoC specific probe where you can call the initialisation in the right order. Tegra is not the first nor the last platform with such issue. Is there anything we could do better at the DT or driver registration level (other than introducing machine_desc)? -- Catalin ^ permalink raw reply [flat|nested] 48+ messages in thread
* [GIT PULL 2/3] ARM: tegra: move fuse code out of arch/arm 2014-07-08 13:43 ` Peter De Schrijver 2014-07-08 17:47 ` Olof Johansson @ 2014-07-18 2:44 ` Stephen Warren 2014-07-18 5:33 ` Olof Johansson 1 sibling, 1 reply; 48+ messages in thread From: Stephen Warren @ 2014-07-18 2:44 UTC (permalink / raw) To: linux-arm-kernel On 07/08/2014 07:43 AM, Peter De Schrijver wrote: > On Mon, Jul 07, 2014 at 02:44:17AM +0200, Olof Johansson wrote: >> On Mon, Jun 23, 2014 at 03:23:45PM -0600, Stephen Warren wrote: >>> This branch moves code related to the Tegra fuses out of arch/arm and >>> into a centralized location which could be shared with ARM64. It also >>> adds support for reading the fuse data through sysfs. >> >> The new/moved misc driver isn't acked by any misc maintainer, so I can't >> take this branch. >> >> I saw no indication from searching the mailing list of that either, >> so it wasn't just a missed acked-by. >> >> I wonder if this code should go under drivers/soc/ instead? > > It's modelled after sunxi_sid.c which lives in drivers/misc/eeprom/. > Originally this driver was also in drivers/misc/eeprom/, but Stephen objected > and therefore it was moved to drivers/misc/fuse. I think that's the right > place still. We anyway need this driver for sata and xhci. Sigh. This is exactly why (a) I suggested during that thread that the driver should be in drivers/soc not drivers/misc and (b) I sent the pull requests early enough so I could deal with any objections before my vacation:-( I wish people would just respond to my review comments by implementing them rather than persuading me to do the wrong thing. Since this is all a dependency for pretty much everything for Tegra for 3.17, I guess we should just drop all the Tegra pull requests for 3.17 and we'll have to redo all the patches for 3.18:-( But if Thierry can (or already has in another thread I haven't seen while on vacation) sort this out be redoing all the Tegra branches, that might be fine too. ^ permalink raw reply [flat|nested] 48+ messages in thread
* [GIT PULL 2/3] ARM: tegra: move fuse code out of arch/arm 2014-07-18 2:44 ` Stephen Warren @ 2014-07-18 5:33 ` Olof Johansson 0 siblings, 0 replies; 48+ messages in thread From: Olof Johansson @ 2014-07-18 5:33 UTC (permalink / raw) To: linux-arm-kernel On Thu, Jul 17, 2014 at 7:44 PM, Stephen Warren <swarren@wwwdotorg.org> wrote: > On 07/08/2014 07:43 AM, Peter De Schrijver wrote: >> On Mon, Jul 07, 2014 at 02:44:17AM +0200, Olof Johansson wrote: >>> On Mon, Jun 23, 2014 at 03:23:45PM -0600, Stephen Warren wrote: >>>> This branch moves code related to the Tegra fuses out of arch/arm and >>>> into a centralized location which could be shared with ARM64. It also >>>> adds support for reading the fuse data through sysfs. >>> >>> The new/moved misc driver isn't acked by any misc maintainer, so I can't >>> take this branch. >>> >>> I saw no indication from searching the mailing list of that either, >>> so it wasn't just a missed acked-by. >>> >>> I wonder if this code should go under drivers/soc/ instead? >> >> It's modelled after sunxi_sid.c which lives in drivers/misc/eeprom/. >> Originally this driver was also in drivers/misc/eeprom/, but Stephen objected >> and therefore it was moved to drivers/misc/fuse. I think that's the right >> place still. We anyway need this driver for sata and xhci. > > Sigh. This is exactly why (a) I suggested during that thread that the > driver should be in drivers/soc not drivers/misc and (b) I sent the pull > requests early enough so I could deal with any objections before my > vacation:-( I wish people would just respond to my review comments by > implementing them rather than persuading me to do the wrong thing. Since > this is all a dependency for pretty much everything for Tegra for 3.17, > I guess we should just drop all the Tegra pull requests for 3.17 and > we'll have to redo all the patches for 3.18:-( But if Thierry can (or > already has in another thread I haven't seen while on vacation) sort > this out be redoing all the Tegra branches, that might be fine too. Thierry has been following up on it, I don't think we're too late for 3.17 yet. -Olof ^ permalink raw reply [flat|nested] 48+ messages in thread
* [GIT PULL 3/3] ARM: tegra: use us counter as delay timer 2014-06-23 21:23 [GIT PULL 1/3] ARM: tegra: rework PCIe regulators Stephen Warren 2014-06-23 21:23 ` [GIT PULL 2/3] ARM: tegra: move fuse code out of arch/arm Stephen Warren @ 2014-06-23 21:23 ` Stephen Warren 2014-07-07 0:49 ` Olof Johansson 2014-07-07 0:38 ` [GIT PULL 1/3] ARM: tegra: rework PCIe regulators Olof Johansson 2 siblings, 1 reply; 48+ messages in thread From: Stephen Warren @ 2014-06-23 21:23 UTC (permalink / raw) To: linux-arm-kernel Tegra has a micro-second counter whose rate doesn't vary with cpufreq changes. Register it so it can be used as the delay timer, so delays aren't influenced by cpufreq. I've made this a separate branch since it touches a few files outside arch/arm/mach-tegra/. This can be merged anywhere that conflicts need to be resolved, although I know of no such places at present. ---------------------------------------------------------------- The following changes since commit 7171511eaec5bf23fb06078f59784a3a0626b38f: Linux 3.16-rc1 are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tegra-for-3.17-delay-timer for you to fetch changes up to 0ff36b4f479ec8e0cd9b7a919ab877f2d553cd30: clocksource: tegra: Use us counter as delay timer ---------------------------------------------------------------- Peter De Schrijver (3): kernel: add calibration_delay_done() ARM: choose highest resolution delay timer clocksource: tegra: Use us counter as delay timer arch/arm/lib/delay.c | 26 ++++++++++++++++++++++---- drivers/clocksource/tegra20_timer.c | 13 +++++++++++++ init/calibrate.c | 11 +++++++++++ 3 files changed, 46 insertions(+), 4 deletions(-) ^ permalink raw reply [flat|nested] 48+ messages in thread
* [GIT PULL 3/3] ARM: tegra: use us counter as delay timer 2014-06-23 21:23 ` [GIT PULL 3/3] ARM: tegra: use us counter as delay timer Stephen Warren @ 2014-07-07 0:49 ` Olof Johansson 0 siblings, 0 replies; 48+ messages in thread From: Olof Johansson @ 2014-07-07 0:49 UTC (permalink / raw) To: linux-arm-kernel On Mon, Jun 23, 2014 at 03:23:46PM -0600, Stephen Warren wrote: > Tegra has a micro-second counter whose rate doesn't vary with cpufreq > changes. Register it so it can be used as the delay timer, so delays > aren't influenced by cpufreq. > > I've made this a separate branch since it touches a few files outside > arch/arm/mach-tegra/. This can be merged anywhere that conflicts need > to be resolved, although I know of no such places at present. > > ---------------------------------------------------------------- > > The following changes since commit 7171511eaec5bf23fb06078f59784a3a0626b38f: > > Linux 3.16-rc1 > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tegra-for-3.17-delay-timer I didn't see an ack from clocksource maintainer on that patch, make sure you get them in the future. I'll take a risk and merge it anyway this time; the change is fairly well-contained. Merged into next/soc. -Olof ^ permalink raw reply [flat|nested] 48+ messages in thread
* [GIT PULL 1/3] ARM: tegra: rework PCIe regulators 2014-06-23 21:23 [GIT PULL 1/3] ARM: tegra: rework PCIe regulators Stephen Warren 2014-06-23 21:23 ` [GIT PULL 2/3] ARM: tegra: move fuse code out of arch/arm Stephen Warren 2014-06-23 21:23 ` [GIT PULL 3/3] ARM: tegra: use us counter as delay timer Stephen Warren @ 2014-07-07 0:38 ` Olof Johansson 2014-07-07 5:52 ` Thierry Reding 2014-07-18 2:47 ` Stephen Warren 2 siblings, 2 replies; 48+ messages in thread From: Olof Johansson @ 2014-07-07 0:38 UTC (permalink / raw) To: linux-arm-kernel On Mon, Jun 23, 2014 at 03:23:44PM -0600, Stephen Warren wrote: > This branch reworks the set of regulators that the Tegra PCIe driver > uses, so that the driver and DT bindings more correctly model what's > really going on in HW. > > I've made this a separate branch in case it needs to be pulled into the > PCIe tree to resolve any conflicts. Any branch that adds Tegra124 > support to the PCIe driver will need to be based on this branch, and > such patches might show up for 3.17, and be taken through the ARM tree > so we can manage our own dependencies. Isn't PCI broken if you boot with an older device tree now? I would like to see this as two branches: One to the PCI driver, and one modifying DT contents. The PCI driver should remain working for old DTs, so the last couple of commits on this branch can't be there. -Olof ^ permalink raw reply [flat|nested] 48+ messages in thread
* [GIT PULL 1/3] ARM: tegra: rework PCIe regulators 2014-07-07 0:38 ` [GIT PULL 1/3] ARM: tegra: rework PCIe regulators Olof Johansson @ 2014-07-07 5:52 ` Thierry Reding 2014-07-08 4:45 ` Olof Johansson 2014-07-18 2:47 ` Stephen Warren 1 sibling, 1 reply; 48+ messages in thread From: Thierry Reding @ 2014-07-07 5:52 UTC (permalink / raw) To: linux-arm-kernel On Sun, Jul 06, 2014 at 05:38:54PM -0700, Olof Johansson wrote: > On Mon, Jun 23, 2014 at 03:23:44PM -0600, Stephen Warren wrote: > > This branch reworks the set of regulators that the Tegra PCIe driver > > uses, so that the driver and DT bindings more correctly model what's > > really going on in HW. > > > > I've made this a separate branch in case it needs to be pulled into the > > PCIe tree to resolve any conflicts. Any branch that adds Tegra124 > > support to the PCIe driver will need to be based on this branch, and > > such patches might show up for 3.17, and be taken through the ARM tree > > so we can manage our own dependencies. > > Isn't PCI broken if you boot with an older device tree now? Yes. > I would like to see this as two branches: One to the PCI driver, and one > modifying DT contents. The PCI driver should remain working for old DTs, > so the last couple of commits on this branch can't be there. This is one of my main gripes with device tree these days. We have many situations where device tree bindings got rushed with the result that many of them describe hardware in a *completely* wrong way. The Tegra PCIe binding was designed with an incomplete understanding of the hardware (I wonder how many other cases there are like this in mainline) and it just happens to work by accident on existing platforms. So this really boils down to one question: how do we fix bugs in device tree bindings? I suppose we could keep some sort of backwards-compatible shim inside the driver to cope with the existing, wrong device tree binding. However that means an additional maintenance burden and I'm not convinced that there's a need in this particular case. Thierry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140707/e2beab94/attachment.sig> ^ permalink raw reply [flat|nested] 48+ messages in thread
* [GIT PULL 1/3] ARM: tegra: rework PCIe regulators 2014-07-07 5:52 ` Thierry Reding @ 2014-07-08 4:45 ` Olof Johansson 2014-07-10 10:15 ` Thierry Reding 0 siblings, 1 reply; 48+ messages in thread From: Olof Johansson @ 2014-07-08 4:45 UTC (permalink / raw) To: linux-arm-kernel On Sun, Jul 6, 2014 at 10:52 PM, Thierry Reding <thierry.reding@gmail.com> wrote: > On Sun, Jul 06, 2014 at 05:38:54PM -0700, Olof Johansson wrote: >> On Mon, Jun 23, 2014 at 03:23:44PM -0600, Stephen Warren wrote: >> > This branch reworks the set of regulators that the Tegra PCIe driver >> > uses, so that the driver and DT bindings more correctly model what's >> > really going on in HW. >> > >> > I've made this a separate branch in case it needs to be pulled into the >> > PCIe tree to resolve any conflicts. Any branch that adds Tegra124 >> > support to the PCIe driver will need to be based on this branch, and >> > such patches might show up for 3.17, and be taken through the ARM tree >> > so we can manage our own dependencies. >> >> Isn't PCI broken if you boot with an older device tree now? > > Yes. > >> I would like to see this as two branches: One to the PCI driver, and one >> modifying DT contents. The PCI driver should remain working for old DTs, >> so the last couple of commits on this branch can't be there. > > This is one of my main gripes with device tree these days. We have many > situations where device tree bindings got rushed with the result that > many of them describe hardware in a *completely* wrong way. > > The Tegra PCIe binding was designed with an incomplete understanding of > the hardware (I wonder how many other cases there are like this in > mainline) and it just happens to work by accident on existing platforms. > > So this really boils down to one question: how do we fix bugs in device > tree bindings? > > I suppose we could keep some sort of backwards-compatible shim inside > the driver to cope with the existing, wrong device tree binding. However > that means an additional maintenance burden and I'm not convinced that > there's a need in this particular case. It's really unfortunate, and this is very likely not the last time we're going to see something like this. Backwards compatibility is only needed where there actually are users of it. Are you absolutely 100% sure that there will not be such a case? Trimslice users? Out-of-tree DTS:es that now need to be fixed up or they will break? This isn't the same thing as in-kernel interface changes where we say "out of tree, out of mind". If you have to stay compatible, then I suggest you try to fill in local driver variables with derivatives of the old properties (and directly from the newer properties where you can). I haven't looked at the specifics here so I don't know how hard it might be. If you are 100% sure that you don't have to stay compatible, then you can remove the code handling the old bindings. Still, even then I am a little worried about dependencies (and more importantly conflicts) between these dtsi changes and others done by tegra platform code for this release. I suppose that can be resolved by having this as a base of any DT changes for tegra if needed. -Olof ^ permalink raw reply [flat|nested] 48+ messages in thread
* [GIT PULL 1/3] ARM: tegra: rework PCIe regulators 2014-07-08 4:45 ` Olof Johansson @ 2014-07-10 10:15 ` Thierry Reding 2014-07-17 14:20 ` Thierry Reding 0 siblings, 1 reply; 48+ messages in thread From: Thierry Reding @ 2014-07-10 10:15 UTC (permalink / raw) To: linux-arm-kernel On Mon, Jul 07, 2014 at 09:45:46PM -0700, Olof Johansson wrote: > On Sun, Jul 6, 2014 at 10:52 PM, Thierry Reding > <thierry.reding@gmail.com> wrote: > > On Sun, Jul 06, 2014 at 05:38:54PM -0700, Olof Johansson wrote: > >> On Mon, Jun 23, 2014 at 03:23:44PM -0600, Stephen Warren wrote: > >> > This branch reworks the set of regulators that the Tegra PCIe driver > >> > uses, so that the driver and DT bindings more correctly model what's > >> > really going on in HW. > >> > > >> > I've made this a separate branch in case it needs to be pulled into the > >> > PCIe tree to resolve any conflicts. Any branch that adds Tegra124 > >> > support to the PCIe driver will need to be based on this branch, and > >> > such patches might show up for 3.17, and be taken through the ARM tree > >> > so we can manage our own dependencies. > >> > >> Isn't PCI broken if you boot with an older device tree now? > > > > Yes. > > > >> I would like to see this as two branches: One to the PCI driver, and one > >> modifying DT contents. The PCI driver should remain working for old DTs, > >> so the last couple of commits on this branch can't be there. > > > > This is one of my main gripes with device tree these days. We have many > > situations where device tree bindings got rushed with the result that > > many of them describe hardware in a *completely* wrong way. > > > > The Tegra PCIe binding was designed with an incomplete understanding of > > the hardware (I wonder how many other cases there are like this in > > mainline) and it just happens to work by accident on existing platforms. > > > > So this really boils down to one question: how do we fix bugs in device > > tree bindings? > > > > I suppose we could keep some sort of backwards-compatible shim inside > > the driver to cope with the existing, wrong device tree binding. However > > that means an additional maintenance burden and I'm not convinced that > > there's a need in this particular case. > > It's really unfortunate, and this is very likely not the last time > we're going to see something like this. > > Backwards compatibility is only needed where there actually are users > of it. Are you absolutely 100% sure that there will not be such a > case? Of course not. Nobody can be absolutely sure about that. > Trimslice users? I think there are two categories here: people that use non-upstream kernels provided by Compulab (because you get all the hardware acceleration goodness) and those that use upstream kernels. Those that use the downstream kernels likely use bindings (if DT at all) that are not supported upstream. And everybody that uses upstream almost certainly uses an upstream U-Boot where it's trivial to update kernel and DTB in one go. And this brings me back to another complaint about DTB: we keep saying things are stable ABI based on the rationale that somebody may have shipped some DT version in a read-only ROM and therefore can't be replaced and thus can't be broken. Today more people are likely to have some version of a downstream DTB in their device that was never supported upstream. And by the above argument we're giving downstream users the finger because it's impossible to update to an upstream kernel. So there's a lot of hypocrisy in that whole argument. > Out-of-tree DTS:es that now need to be fixed up or they will break? Yes, any out-of-tree DTS'es would need to be updated or things will indeed break. There at least one case where an out-of-tree DTS was already updated updated during the process of getting the support upstream (Toradex). > This isn't the same thing as in-kernel interface changes where we say > "out of tree, out of mind". That's exactly the problem. When we started out with the DT conversion this was never mentioned. Maybe some people always took this for granted but certainly not all. Most of the device tree bindings back at the time were pulled out of a hat. Many were subsequently changed because they didn't work out as expected. Until the big discussions around ABI stability started. > If you have to stay compatible, then I suggest you try to fill in > local driver variables with derivatives of the old properties (and > directly from the newer properties where you can). I haven't looked at > the specifics here so I don't know how hard it might be. > > If you are 100% sure that you don't have to stay compatible, then you > can remove the code handling the old bindings. Still, even then I am a > little worried about dependencies (and more importantly conflicts) > between these dtsi changes and others done by tegra platform code for > this release. I suppose that can be resolved by having this as a base > of any DT changes for tegra if needed. To be honest, I'm very much tempted to just drop this series. Even if that means keeping a totally broken DT binding. But frankly I don't have any energy left to debate DT stability. Thierry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140710/2b71ebf6/attachment.sig> ^ permalink raw reply [flat|nested] 48+ messages in thread
* [GIT PULL 1/3] ARM: tegra: rework PCIe regulators 2014-07-10 10:15 ` Thierry Reding @ 2014-07-17 14:20 ` Thierry Reding 2014-07-17 17:52 ` Olof Johansson 0 siblings, 1 reply; 48+ messages in thread From: Thierry Reding @ 2014-07-17 14:20 UTC (permalink / raw) To: linux-arm-kernel On Thu, Jul 10, 2014 at 12:15:28PM +0200, Thierry Reding wrote: > On Mon, Jul 07, 2014 at 09:45:46PM -0700, Olof Johansson wrote: [...] > > If you have to stay compatible, then I suggest you try to fill in > > local driver variables with derivatives of the old properties (and > > directly from the newer properties where you can). I haven't looked at > > the specifics here so I don't know how hard it might be. > > > > If you are 100% sure that you don't have to stay compatible, then you > > can remove the code handling the old bindings. Still, even then I am a > > little worried about dependencies (and more importantly conflicts) > > between these dtsi changes and others done by tegra platform code for > > this release. I suppose that can be resolved by having this as a base > > of any DT changes for tegra if needed. > > To be honest, I'm very much tempted to just drop this series. Even if > that means keeping a totally broken DT binding. But frankly I don't have > any energy left to debate DT stability. So this kept bugging me and I couldn't leave it alone after all. How about if I squash in the attached patch. I've verified that that keeps compatibility with old device trees on TrimSlice and Beaver. I think the remainder of the series could still remain as-is (the top few commits that you said shouldn't be there) if I squash this into PCI: tegra: Implement accurate power supply scheme That way the binding will be the new one so that people don't get any wrong ideas about taking shortcuts while still preserving compatibility with existing DTBs. Interestingly, despite my initial disgust for having to keep around old code (it's in fact new code in this case) for compatibility reasons, it ended up making the code look more mature. Thierry -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-PCI-tegra-Preserve-DT-backwards-compatibility.patch Type: text/x-diff Size: 3572 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140717/2f969e7c/attachment-0001.bin> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140717/2f969e7c/attachment-0001.sig> ^ permalink raw reply [flat|nested] 48+ messages in thread
* [GIT PULL 1/3] ARM: tegra: rework PCIe regulators 2014-07-17 14:20 ` Thierry Reding @ 2014-07-17 17:52 ` Olof Johansson 0 siblings, 0 replies; 48+ messages in thread From: Olof Johansson @ 2014-07-17 17:52 UTC (permalink / raw) To: linux-arm-kernel On Thu, Jul 17, 2014 at 7:20 AM, Thierry Reding <thierry.reding@gmail.com> wrote: > On Thu, Jul 10, 2014 at 12:15:28PM +0200, Thierry Reding wrote: >> On Mon, Jul 07, 2014 at 09:45:46PM -0700, Olof Johansson wrote: > [...] >> > If you have to stay compatible, then I suggest you try to fill in >> > local driver variables with derivatives of the old properties (and >> > directly from the newer properties where you can). I haven't looked at >> > the specifics here so I don't know how hard it might be. >> > >> > If you are 100% sure that you don't have to stay compatible, then you >> > can remove the code handling the old bindings. Still, even then I am a >> > little worried about dependencies (and more importantly conflicts) >> > between these dtsi changes and others done by tegra platform code for >> > this release. I suppose that can be resolved by having this as a base >> > of any DT changes for tegra if needed. >> >> To be honest, I'm very much tempted to just drop this series. Even if >> that means keeping a totally broken DT binding. But frankly I don't have >> any energy left to debate DT stability. > > So this kept bugging me and I couldn't leave it alone after all. How > about if I squash in the attached patch. I've verified that that keeps > compatibility with old device trees on TrimSlice and Beaver. I think the > remainder of the series could still remain as-is (the top few commits > that you said shouldn't be there) if I squash this into > > PCI: tegra: Implement accurate power supply scheme > > That way the binding will be the new one so that people don't get any > wrong ideas about taking shortcuts while still preserving compatibility > with existing DTBs. Taking a quick look at the patch, it looks sane to me and pretty much exactly what I would expect the code to look like w.r.t. handling old bindings. > Interestingly, despite my initial disgust for having to keep around old > code (it's in fact new code in this case) for compatibility reasons, it > ended up making the code look more mature. I'm glad it went that way. It shouldn't be _too_ bad to keep the compatibility with old bindings in the code like this in most cases, it's mostly a matter of filling in the newer structures like you did in this patch. -Olof ^ permalink raw reply [flat|nested] 48+ messages in thread
* [GIT PULL 1/3] ARM: tegra: rework PCIe regulators 2014-07-07 0:38 ` [GIT PULL 1/3] ARM: tegra: rework PCIe regulators Olof Johansson 2014-07-07 5:52 ` Thierry Reding @ 2014-07-18 2:47 ` Stephen Warren 1 sibling, 0 replies; 48+ messages in thread From: Stephen Warren @ 2014-07-18 2:47 UTC (permalink / raw) To: linux-arm-kernel On 07/06/2014 06:38 PM, Olof Johansson wrote: > On Mon, Jun 23, 2014 at 03:23:44PM -0600, Stephen Warren wrote: >> This branch reworks the set of regulators that the Tegra PCIe driver >> uses, so that the driver and DT bindings more correctly model what's >> really going on in HW. >> >> I've made this a separate branch in case it needs to be pulled into the >> PCIe tree to resolve any conflicts. Any branch that adds Tegra124 >> support to the PCIe driver will need to be based on this branch, and >> such patches might show up for 3.17, and be taken through the ARM tree >> so we can manage our own dependencies. > > Isn't PCI broken if you boot with an older device tree now? > > I would like to see this as two branches: One to the PCI driver, and one > modifying DT contents. The PCI driver should remain working for old DTs, > so the last couple of commits on this branch can't be there. I thought it was still completely legal to change DT bindings that were not yet considered stable. None of the Tegra bindings have yet been deemed stable. ^ permalink raw reply [flat|nested] 48+ messages in thread
end of thread, other threads:[~2014-07-24 17:12 UTC | newest] Thread overview: 48+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-06-23 21:23 [GIT PULL 1/3] ARM: tegra: rework PCIe regulators Stephen Warren 2014-06-23 21:23 ` [GIT PULL 2/3] ARM: tegra: move fuse code out of arch/arm Stephen Warren 2014-07-07 0:44 ` Olof Johansson 2014-07-08 13:43 ` Peter De Schrijver 2014-07-08 17:47 ` Olof Johansson 2014-07-09 11:16 ` Peter De Schrijver 2014-07-09 12:50 ` Arnd Bergmann 2014-07-11 12:56 ` Thierry Reding 2014-07-18 2:45 ` Stephen Warren 2014-07-18 5:33 ` Olof Johansson 2014-07-21 15:06 ` Stephen Warren 2014-07-21 15:54 ` Catalin Marinas 2014-07-21 16:14 ` Pawel Moll 2014-07-21 16:38 ` Stephen Warren 2014-07-21 16:46 ` Olof Johansson 2014-07-21 17:00 ` [PATCH] platform: Make platform_bus device a platform device Pawel Moll 2014-07-21 18:40 ` Greg Kroah-Hartman 2014-07-22 10:02 ` [PATCH v2] " Pawel Moll 2014-07-22 17:10 ` Greg Kroah-Hartman 2014-07-22 17:30 ` Pawel Moll 2014-07-22 17:37 ` Greg Kroah-Hartman 2014-07-22 17:55 ` [PATCH v3] " Pawel Moll 2014-07-22 18:01 ` Pawel Moll 2014-07-22 18:15 ` Greg Kroah-Hartman 2014-07-23 17:16 ` Pawel Moll 2014-07-23 19:34 ` Greg Kroah-Hartman 2014-07-24 17:12 ` Pawel Moll 2014-07-22 19:46 ` Olof Johansson 2014-07-23 14:26 ` Pawel Moll 2014-07-22 22:16 ` Greg Kroah-Hartman 2014-07-23 14:27 ` Pawel Moll 2014-07-22 10:27 ` [GIT PULL 2/3] ARM: tegra: move fuse code out of arch/arm Catalin Marinas 2014-07-22 16:27 ` Stephen Warren 2014-07-22 16:54 ` Catalin Marinas 2014-07-22 11:26 ` Catalin Marinas 2014-07-22 16:22 ` Stephen Warren 2014-07-22 17:04 ` Catalin Marinas 2014-07-18 2:44 ` Stephen Warren 2014-07-18 5:33 ` Olof Johansson 2014-06-23 21:23 ` [GIT PULL 3/3] ARM: tegra: use us counter as delay timer Stephen Warren 2014-07-07 0:49 ` Olof Johansson 2014-07-07 0:38 ` [GIT PULL 1/3] ARM: tegra: rework PCIe regulators Olof Johansson 2014-07-07 5:52 ` Thierry Reding 2014-07-08 4:45 ` Olof Johansson 2014-07-10 10:15 ` Thierry Reding 2014-07-17 14:20 ` Thierry Reding 2014-07-17 17:52 ` Olof Johansson 2014-07-18 2:47 ` Stephen Warren
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).