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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.