[PATCH 3/3] mpc52xx/wdt: WDT uses GPT api
Wim Van Sebroeck
wim at iguana.be
Wed Dec 9 07:48:54 EST 2009
Hi Grant,
Sorry for the delay, I need to deliver a project in a weeks time...
> In actual fact, it is a single device with multiple functions, some of
> which can be used at the same time. The driver for the device
> determines what the device instance supports and registers the
> appropriate interfaces. There is a GPIO controller, a PWM controller,
> a general purpose timer, and the watchdog. Because of the
> multifunction nature of the device, there are subtle interactions
> between the functions that the driver needs to maintain. I don't want
> to export functions from the driver which will only be used by a
> watchdog instance. I also don't want the added code and complexity of
> a secondary probe path. It is simpler and less code to roll all the
> behaviour up into the one driver single driver that gets probed once.
>
> >From the maintenance perspective, having the main driver in
> arch/powerpc and the watchdog bit in drivers/watchdog doesn't really
> help much anyway because anything that changes the internal driver API
> (between the core and watchdog bits) will require cross-maintainer
> changes. ie. do changes go through my tree because they touch
> arch/powerpc, or do they go through yours because they touch
> drivers/watchdog? I'd much rather all the internal details be
> contained within a single driver.
Your argument about maintenance is the same one as I have: If all watchdog
driver pieces are under drivers/watchdog then it's easier for me to maintain
them. (Definitely if we are doing clean-up work and API changes).
> Besides, there is already precedence for very arch-specific drivers
> living under arch/*/. find ./arch -name *gpio*
But in this case: I know where to find them and I will keep a mental note
about this one. And yes indeed some very arch specific drivers can reside
under arch/*/* .
So please go ahead with pulling this one in a single driver.
Kind regards,
Wim.
More information about the devicetree-discuss
mailing list