Re: [PATCH v4 1/2] ARM: mach-moxart: add MOXA ART SoC platform files

[Arnd Bergmann <arnd@arndb.de>]

On Saturday 14 December 2013, Guenter Roeck wrote:
> Hmm ... not sure I agree. I don't see a problem with something like "arm,moxart-reboot".
> There are already vexpress-reboot and xgene-reboot properties which do pretty much
> the same.
> 
> Actually, you don't even need that; the reset driver could simply re-use the
> "moxa,moxart-watchdog" property. After all, all that specifies is that there
> is a compatible driver. Look for "samsung,s3c2410-wdt" for an example of another
> reset handler doing just that.
> 
> Attaching it to the watchdog device seems to be more problematic given the
> (currently) optional nature of the watchdog driver and its different scope.

As far as I'm concerned a watchdog driver is just as optional as a reboot
driver. The vexpress and xgene reset drivers are different because those
are actually dedicated devices that are there only to do rebooting.

The "samsung,s3c2410-wdt" device is exactly the same category as the moxart
one, but the code to use it performs the same hack by scanning the
device tree ad hoc from the platform initialization. I think it should
be integrated into watchdog the same way, and if we have more drivers
in that category, we'd probably want a generic watchdog reboot callback
function that wdt drivers can hook up to the architecture reset handler.

The main difference I see between plat-samsung and mach-moxart here is that
the samsung platforms still need a lot of code in arch/arm to get things
to work (this will have to change as soon as we get an arm64 exynos, which
would have everything in proper drivers), while for moxart this is the only
non-driver code.

Reusing the moxa,moxart-watchdog device from a separate reboot driver is
a violation of the driver model, since we can't really bind two platform
drivers to one platform device, unless you add another device in drivers/mfd
to create two children for wdt and reboot, but that would be really silly.
You could use the same code that samsung has at the moment in a loadable
module, which effectively implements a linux-2.4 style driver that probes
the device in the module_init function rather than registering a struct
device_driver with a probe callback.

	Arnd