public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Greg KH <gregkh@linuxfoundation.org>,
	David Brown <davidb@codeaurora.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Nicolas Pitre <nico@fluxnic.net>
Subject: Re: [GIT PATCH] char/misc patches for 3.10-rc1
Date: Mon, 29 Apr 2013 21:54:15 +0200	[thread overview]
Message-ID: <201304292154.15920.arnd@arndb.de> (raw)
In-Reply-To: <CA+55aFzLtBwsvVrnT2DrUOU+eYrQ5eiKeamRb4Y5+-TVgbuM5Q@mail.gmail.com>

On Monday 29 April 2013, Linus Torvalds wrote:
> And I'm calling the ARM people out on this idiocy. Arnd and Nico -
> stop encouraging this kind of crap. Move things to drivers only once
> there is actual reason for it. If it's some proprierary single-SoC
> thing, it can damn well stay away from other people. And it definitely
> shouldn't mess up autocomplete in some core location.

First of all, I have to admit that I did not notice ssbi getting submitted,
otherwise I would have suggested adding it to the drivers/bus directory
that we created a while ago for bus drivers.

I think there are good reasons for most of the drivers we have moved out
of arch/arm to stay out of there: we have added subdirectories for a lot
of drivers that are alike:

* drivers/irqchip
* drivers/clocksource
* drivers/cpufreq
* drivers/pinctrl
* drivers/pci/host
* drivers/pwm

All of these (and probably a couple I missed) now have a subsystem
maintainer who can look at the bigger picture across multiple platforms,
create common infrastructure to avoid code duplication and point out
when people create new drivers for hardware that already has an
existing driver in the same subsystem (this happens more than you'd
think).

Moreoever, a lot of ARM platforms in share even the most basic
building blocks with platforms on other architectures: powerpc,
mips, hexagon, c6x, sh, and even x86. I think it's much better to
consistently move those drivers into on directory per subsystem
rather than having only half the irqchip drivers in one directory
when they are shared across two architectures, and the rest hidden
away in some platform. In the end, it's not much different from
having a platform specific network driver sit under
drivers/net/ethernet rather than arch/arm/mach-foo even if we
know it's never going to be used elsewhere.
In case of SSBI, I assume it's also being used by arch/hexagon,
which is the other CPU core on many Qualcomm SoCs, but I'm sure
that David can comment better on that one, maybe it's only used
exclusively on SoCs that are ARM-only.

I think about two years ago, I tried to move a lot of simple "bus"
drivers into a common drivers/bus/ directory: amba, bcma, dio, eisa, hsi,
nubus, vlynq, vme, zorro out of their own top-level drivers directory.
That idea was almost universally rejected.

I did ask people submitting new bus infrastructure to use drivers/bus
though, and at least three of them were subsequently merged that way
(or are queued up for this merge window). If you like, we can try to
find a different place for those along with ssbi.

	Arnd

  reply	other threads:[~2013-04-29 19:54 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-29 16:21 [GIT PATCH] char/misc patches for 3.10-rc1 Greg KH
2013-04-29 18:28 ` Linus Torvalds
2013-04-29 18:38   ` Greg KH
2013-04-29 18:55     ` Linus Torvalds
2013-04-29 19:02       ` Linus Torvalds
2013-04-29 19:15       ` Linus Torvalds
2013-04-29 19:54         ` Arnd Bergmann [this message]
2013-04-29 20:12           ` Linus Torvalds
2013-04-29 20:50             ` Arnd Bergmann
2013-04-29 21:13               ` Linus Torvalds
2013-04-29 21:22                 ` Arnd Bergmann
2013-05-01 16:12               ` Mark Brown
2013-04-29 21:08             ` David Brown
2013-04-29 21:16               ` Arnd Bergmann
2013-05-01 16:13                 ` Mark Brown
2013-05-02 20:53                   ` David Brown
2013-05-03  8:06                     ` Mark Brown
2013-04-29 21:18               ` Linus Torvalds
2013-04-29 21:29                 ` Arnd Bergmann
2013-04-29 22:00                 ` MFD: move ssbi driver into drivers/mfd Arnd Bergmann
2013-04-29 22:10                   ` Greg KH
2013-04-29 22:48                   ` Nicolas Pitre
2013-04-30  0:00                   ` David Brown
2013-04-30 10:18                   ` Samuel Ortiz
2013-04-30 10:26                     ` Arnd Bergmann
2013-05-16  9:49                   ` Samuel Ortiz
2013-04-29 20:45         ` [GIT PATCH] char/misc patches for 3.10-rc1 Nicolas Pitre

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=201304292154.15920.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=akpm@linux-foundation.org \
    --cc=davidb@codeaurora.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nico@fluxnic.net \
    --cc=torvalds@linux-foundation.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