From: Guenter Roeck <linux@roeck-us.net>
To: Jean Delvare <jdelvare@suse.de>, Wim Van Sebroeck <wim@iguana.be>
Cc: linux-watchdog <linux-watchdog@vger.kernel.org>
Subject: Re: Watchdog drivers and device driver model
Date: Fri, 07 Mar 2014 06:37:14 -0800 [thread overview]
Message-ID: <5319D99A.50003@roeck-us.net> (raw)
In-Reply-To: <1394199268.4376.50.camel@chaos.site>
On 03/07/2014 05:34 AM, Jean Delvare wrote:
> Hi Wim and all,
>
> While investigating a customer case, it occurred to me that it is not
> always possible to figure out which driver is handling /dev/watchdog.
> For some drivers, /sys/dev/char/10:130 is a symbolic link
> to /sys/devices/virtual/misc/watchdog, and that virtual device says
> nothing about the physical device nor the device driver.
>
> As far as I can see, this happens whenever the dev.parent field of the
> watchdog_device structure isn't set before calling
> watchdog_register_device(). Couldn't we make setting this field
> mandatory, so that it is always possible to get to the physical device?
> It seems that only a minority of watchdog drivers are doing it properly
> at the moment.
>
> Also, it seems to me that at least in some cases, the parent device that
> is set isn't the right one. I am looking at the iTCO_wdt driver, it puts
> the PCI device as the parent, however the driver itself is a platform
> driver so it is attached to the iTCO_wdt platform device. That makes it
> impossible to find which driver is handling /dev/watchdog in an
> automated way: both /sys/dev/char/10:130
> and /sys/class/watchdog/watchdog0 point to the PCI device, which has
> driver "lpc_ich" attached, not "iTCO_wdt". One has to enter the iTCO_wdt
> directory there to find the proper driver. May I suggest that dev.parent
> should point to the iTCO_wdt platform device in that case?
>
Good idea. I've had trouble identifying watchdogs myself, and it would
be great to have a reliable means to do it.
> If you need some background: my customer needs to unload the native
> watchdog driver and use the IPMI watchdog instead. So they need a
> reliable way to figure out who is handling /dev/watchdog so that they
> can unload the right module. This is rather difficult, costly and
> fragile with the way things are currently implemented.
>
Another solution in that specific case would be to convert the ipmi
watchdog driver to the watchdog API. Then it could be loaded in parallel
with other watchdog drivers. Of course, the naming problem would still
exist.
Guenter
next prev parent reply other threads:[~2014-03-07 14:37 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-07 13:34 Watchdog drivers and device driver model Jean Delvare
2014-03-07 14:37 ` Guenter Roeck [this message]
2014-03-07 15:30 ` Jean Delvare
2014-03-07 17:29 ` Guenter Roeck
2014-03-08 12:27 ` Jean Delvare
2014-03-08 14:12 ` Guenter Roeck
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=5319D99A.50003@roeck-us.net \
--to=linux@roeck-us.net \
--cc=jdelvare@suse.de \
--cc=linux-watchdog@vger.kernel.org \
--cc=wim@iguana.be \
/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.