From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V7 1/2] ARM: bcm281xx: Add timer driver (driver portion)
Date: Thu, 14 Mar 2013 16:03:02 +0000 [thread overview]
Message-ID: <201303141603.02401.arnd@arndb.de> (raw)
In-Reply-To: <alpine.LFD.2.02.1303140951580.22263@ionos>
On Thursday 14 March 2013, Thomas Gleixner wrote:
> > But if its arch specific for hardware I don't have, I'd really prefer the arch
> > maintainer be the upstream path.
> >
> > Thomas: Am I being too obstinate here? If not, should we drop "F:
> > drivers/clocksource" from the MAINTAINERS entry?
The idea of moving drivers out of arch/* into drivers/* is definitely to
have someone who understands the subsystem act as the gatekeeper. There
should be very little architecture specific knowledge in those drivers,
and I think it's more important to ensure that they are following a
sensible understanding of how timekeeping is done than that they
are following specific architecture maintainer's preferences.
> Maybe we should move the ARM specific ones into
> drivers/clocksource/arm/ ?
About half the IP blocks we use on ARM are also used on at least
one ARM64/AVR32/MIPS/PowerPC/x86/SH/Hexagon/c6x/etc part. Grouping them
by which CPU architecture first starts using them or happens to be
more popular at the time does not seem too helpful here.
Maybe it's better to have a subdirectory for those clock sources
that are used on any SoC, or have subdirectories based on the
company that created that part, as we do for ethernet drivers.
I wouldn't bother with that until there are a couple of dozen
different clock source drivers.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
To: Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
Cc: Russell King <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>,
Christian Daudt <csd-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
"arm-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org"
<arm-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
John Stultz <john.stultz-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [PATCH V7 1/2] ARM: bcm281xx: Add timer driver (driver portion)
Date: Thu, 14 Mar 2013 16:03:02 +0000 [thread overview]
Message-ID: <201303141603.02401.arnd@arndb.de> (raw)
In-Reply-To: <alpine.LFD.2.02.1303140951580.22263@ionos>
On Thursday 14 March 2013, Thomas Gleixner wrote:
> > But if its arch specific for hardware I don't have, I'd really prefer the arch
> > maintainer be the upstream path.
> >
> > Thomas: Am I being too obstinate here? If not, should we drop "F:
> > drivers/clocksource" from the MAINTAINERS entry?
The idea of moving drivers out of arch/* into drivers/* is definitely to
have someone who understands the subsystem act as the gatekeeper. There
should be very little architecture specific knowledge in those drivers,
and I think it's more important to ensure that they are following a
sensible understanding of how timekeeping is done than that they
are following specific architecture maintainer's preferences.
> Maybe we should move the ARM specific ones into
> drivers/clocksource/arm/ ?
About half the IP blocks we use on ARM are also used on at least
one ARM64/AVR32/MIPS/PowerPC/x86/SH/Hexagon/c6x/etc part. Grouping them
by which CPU architecture first starts using them or happens to be
more popular at the time does not seem too helpful here.
Maybe it's better to have a subdirectory for those clock sources
that are used on any SoC, or have subdirectories based on the
company that created that part, as we do for ethernet drivers.
I wouldn't bother with that until there are a couple of dozen
different clock source drivers.
Arnd
next prev parent reply other threads:[~2013-03-14 16:03 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-13 21:27 [PATCH V7 1/2] ARM: bcm281xx: Add timer driver (driver portion) Christian Daudt
2013-03-13 21:27 ` Christian Daudt
2013-03-13 21:27 ` [PATCH V7 2/2] ARM: bcm281xx: Add timer driver (DT portion) Christian Daudt
2013-03-13 21:27 ` Christian Daudt
2013-03-28 16:07 ` Christian Daudt
2013-03-28 16:07 ` Christian Daudt
2013-04-02 20:43 ` Olof Johansson
2013-04-02 20:43 ` Olof Johansson
2013-04-02 20:41 ` Olof Johansson
2013-04-02 20:41 ` Olof Johansson
2013-03-13 23:29 ` [PATCH V7 1/2] ARM: bcm281xx: Add timer driver (driver portion) John Stultz
2013-03-13 23:29 ` John Stultz
2013-03-14 9:16 ` Thomas Gleixner
2013-03-14 9:16 ` Thomas Gleixner
2013-03-14 16:03 ` Arnd Bergmann [this message]
2013-03-14 16:03 ` Arnd Bergmann
2013-03-28 16:03 ` Christian Daudt
2013-03-28 16:03 ` Christian Daudt
2013-03-28 17:57 ` John Stultz
2013-03-28 17:57 ` John Stultz
2013-03-28 19:27 ` Arnd Bergmann
2013-03-28 19:27 ` Arnd Bergmann
2013-03-28 18:01 ` John Stultz
2013-03-28 18:01 ` John Stultz
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=201303141603.02401.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is 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.