From mboxrd@z Thu Jan 1 00:00:00 1970 From: john.stultz@linaro.org (John Stultz) Date: Wed, 13 Mar 2013 16:29:56 -0700 Subject: [PATCH V7 1/2] ARM: bcm281xx: Add timer driver (driver portion) In-Reply-To: <1363210048-3334-1-git-send-email-csd@broadcom.com> References: <1363210048-3334-1-git-send-email-csd@broadcom.com> Message-ID: <51410BF4.4040400@linaro.org> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 03/13/2013 02:27 PM, Christian Daudt wrote: > This adds support for the Broadcom timer, used in the following SoCs: > BCM11130, BCM11140, BCM11351, BCM28145, BCM28155 [snip] > Signed-off-by: Christian Daudt > Acked-by: Arnd Bergmann > Acked-by: John Stultz > Reviewed-by: Stephen Warren Hey Olof, So Christian mentioned you were hoping I'd pull these in through my tree, but I'd really rather these go via the arch-soc tree, since that is more likely where they will be tested and more intelligently reviewed. I've mentioned before my distaste for the drivers/clocksource directory becoming a dumping ground for arch specific (for the most part arm) clocksource, and more recently clockevent, drivers. I initially wanted the drivers/clocksource directory to be only for cross-arch clocksources, and I fear we'll end up with something like the drivers/rtc directory where its not entirely clear what hardware you actually need for a given driver (might as well be rtc-.c ;). That said, I realize I've been overruled on this. :) But I'd really rather the patch flow for arch specific clocksource and clockevent drivers go through the arch tree, since there's a better chance folks will be building and testing against other arch specific changes that might cause problems. There's just no way for me to be able to intelligently review these sorts of changes. Now, if there are changes to the clocksource core code, then I definitely want to be in the path there. Additionally meta-drivers like mmio, I should probably be more involved with, so they can be more properly integrated into the clocksource core. Also for drivers that are actually arch shared (ie: things like hpet/acpi_pm where ia64 and x86 share them). 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? Christian: Sorry for the confusion on all this! thanks -john