On Mon, Apr 2, 2018 at 9:32 AM, Andrew Lunn <andrew@xxxxxxx> wrote: >> The 'use case' we have been using this in for a couple years is that >> users who want to use this watchdog will enable it externally (we have >> a command in the bootloader) and if enabled the kernel driver (that >> I'm proposing here which we've been using out-of-tree) will register >> the watchdog device and the userspace watchdog process can open the >> device and start tickling it. If the watchdog is never enabled (or >> disabled via the bootloader command) the kernel driver fails to probe >> and the SoC's watchdog can be used. > > Hi Tim > > Is there any reason not to give the user the choice to use both > watchdogs? Normally you write drivers to expose the hardware, and then > let the users choice if they want to use it. > Andrew, I don't know what value the SoC watchdog has if you have the GSC watchdog available that can power cycle the board but I would agree normally you would expose all of them. I suppose this may be a different case because I'm expecting the user to go and manually enable the watchdog instead of using the kernel to do it which means if its not enabled its not really available to be used. Tim -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
