From: robherring2@gmail.com (Rob Herring)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 00/15] mach/io.h cleanup and removal
Date: Tue, 14 Feb 2012 15:54:14 -0600 [thread overview]
Message-ID: <4F3AD806.50402@gmail.com> (raw)
In-Reply-To: <201202142126.49849.arnd@arndb.de>
On 02/14/2012 03:26 PM, Arnd Bergmann wrote:
> On Tuesday 14 February 2012, Tony Lindgren wrote:
>>> c) Don't allow mach includes in drivers and sound dirs for
>>> multi-platform kernels. This is already the case for any multi-arch
>>> driver. A lot of the headers are platform_data structs or things that
>>> should be cleaned up or need common infrastructure. Some cases I've
>>> found seem like the include is unnecessary. Also, just fixing up the
>>> name or path is no guarantee of avoiding namespace collisions.
>>
>> Out of the three options c) makes most sense for multi-subarch kernels.
>> And that avoids having to sort out the name collisions with defines.
>
> I agree that this is the ideal, but as far as I can tell, we have a
> significant amount of functions that are defined in platform specific
> code but used in platform specific drivers. E.g. when you have a
> piece of code dealing with system management registers in your platform,
> that would be used in the cpufreq, irqchip, watchdog and more drivers.
>From my quick survey, those categories are really the exception. I would
guess platform_data structs is at least half of it. Older platforms seem
to be another big chunk.
Lack of a common usb phy infrastructure is another example of custom
platform functions (tegra usb_phy.h).
> There has to be some place where we can put function declarations
> for stuff like this, while at the same time we should try to minimise
> the amount that is required.
>
>> For dealing with legacy platforms, I too would prefer b).
>
> How about this:
>
> * We stop providing arch/arm/{mach,plat}-*/include/ to C files
> outside of arch/arm/{mach,plat}-* when CONFIG_MULTIPLATFORM is
> enabled.
>
> * Any symbol that is required to be visible in device drivers
> gets declared in arch/arm/include/mach-*/*.h, but we are very
> careful about adding only the absolute minimum here.
Why not include/linux? Any includes for drivers which are either
multiple arches (ahci_platform.h) or multiple ARM machines
(linux/amba/pl061.h) are already there. Every platform trying to dump
dozens of includes there would certainly get attention and force some
clean-up.
Rob
next prev parent reply other threads:[~2012-02-14 21:54 UTC|newest]
Thread overview: 74+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-13 21:43 [PATCH 00/15] mach/io.h cleanup and removal Rob Herring
2012-02-13 21:43 ` [PATCH 01/15] usb: ohci-pxa27x: add explicit include of hardware.h Rob Herring
2012-02-13 21:43 ` [PATCH 02/15] ARM: add explicit include of system.h to processor.h Rob Herring
2012-02-13 22:14 ` H Hartley Sweeten
2012-02-13 21:43 ` [PATCH 03/15] ARM: provide runtime hook for ioremap Rob Herring
2012-02-13 22:13 ` H Hartley Sweeten
2012-02-13 22:30 ` Russell King - ARM Linux
2012-02-13 22:48 ` Rob Herring
2012-02-13 21:43 ` [PATCH 04/15] ARM: imx: convert to common runtime ioremap hook Rob Herring
2012-02-16 0:17 ` Shawn Guo
2012-02-13 21:43 ` [PATCH 05/15] ARM: msm: use " Rob Herring
2012-02-13 23:05 ` David Brown
2012-02-13 21:43 ` [PATCH 06/15] ARM: msm: clean-up mach/io.h Rob Herring
2012-02-13 21:43 ` [PATCH 07/15] ARM: at91: " Rob Herring
2012-02-14 9:21 ` Nicolas Ferre
2012-02-14 13:24 ` Rob Herring
2012-02-16 7:43 ` Jean-Christophe PLAGNIOL-VILLARD
2012-02-16 14:08 ` Rob Herring
2012-02-16 14:23 ` Jean-Christophe PLAGNIOL-VILLARD
2012-02-23 17:26 ` Nicolas Ferre
2012-02-27 16:55 ` Rob Herring
2012-02-27 17:27 ` Jean-Christophe PLAGNIOL-VILLARD
2012-02-13 21:43 ` [PATCH 08/15] ARM: davinci: remove unneeded mach/io.h include Rob Herring
2012-02-13 21:43 ` [PATCH 09/15] ARM: orion5x: clean-up mach/io.h Rob Herring
2012-02-13 21:43 ` [PATCH 10/15] ARM: tegra: " Rob Herring
2012-02-13 21:43 ` [PATCH 11/15] ARM: ep93xx: " Rob Herring
2012-02-13 21:52 ` Ryan Mallon
2012-02-13 22:15 ` Rob Herring
2012-02-13 22:16 ` H Hartley Sweeten
2012-02-27 15:17 ` [PATCH] " Rob Herring
2012-02-13 21:43 ` [PATCH 12/15] ARM: clps711x: remove unneeded include of mach/io.h Rob Herring
2012-02-13 21:43 ` [PATCH 13/15] ARM: make mach/io.h include optional Rob Herring
2012-02-13 22:14 ` H Hartley Sweeten
2012-02-13 22:36 ` Russell King - ARM Linux
2012-02-13 22:55 ` Rob Herring
2012-02-14 2:03 ` Arnd Bergmann
2012-02-14 2:54 ` Rob Herring
2012-02-14 8:04 ` Arnd Bergmann
2012-02-14 14:36 ` Rob Herring
2012-02-14 17:16 ` Arnd Bergmann
2012-02-14 17:40 ` Russell King - ARM Linux
2012-02-14 18:12 ` Arnd Bergmann
2012-02-14 23:09 ` Rob Herring
2012-02-14 23:43 ` Russell King - ARM Linux
2012-02-15 0:25 ` Nicolas Pitre
2012-02-15 14:14 ` Rob Herring
2012-02-15 0:57 ` Arnd Bergmann
2012-02-27 19:31 ` Rob Herring
2012-02-28 16:10 ` Arnd Bergmann
2012-02-27 22:31 ` Rob Herring
2012-02-28 16:32 ` Arnd Bergmann
2012-02-13 23:15 ` H Hartley Sweeten
2012-02-14 1:06 ` Arnd Bergmann
2012-02-14 17:38 ` H Hartley Sweeten
2012-02-14 18:20 ` Arnd Bergmann
2012-02-13 21:43 ` [PATCH 14/15] ARM: remove bunch of now unused mach/io.h files Rob Herring
2012-02-13 22:16 ` H Hartley Sweeten
2012-02-16 0:19 ` Shawn Guo
2012-02-16 18:57 ` Linus Walleij
2012-02-13 21:43 ` [PATCH 15/15] ARM: kill off __mem_pci Rob Herring
2012-02-13 22:22 ` [PATCH 00/15] mach/io.h cleanup and removal Tony Lindgren
2012-02-13 23:56 ` Tony Lindgren
2012-02-14 3:09 ` Rob Herring
2012-02-13 23:41 ` Tony Lindgren
2012-02-14 3:20 ` Rob Herring
2012-02-14 17:24 ` Tony Lindgren
2012-02-14 17:57 ` Arnd Bergmann
2012-02-14 18:28 ` Nicolas Pitre
2012-02-14 19:41 ` Rob Herring
2012-02-14 20:43 ` Tony Lindgren
2012-02-14 21:26 ` Arnd Bergmann
2012-02-14 21:54 ` Rob Herring [this message]
2012-02-14 22:38 ` Arnd Bergmann
2012-02-21 22:47 ` Stephen Warren
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F3AD806.50402@gmail.com \
--to=robherring2@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).