> -----Original Message-----
> From: Guenter Roeck [mailto:[email protected]]
> Sent: Sunday, January 03, 2016 17:48
> To: Winkler, Tomas; Wim Van Sebroeck
> Cc: [email protected]
> Subject: Re: [watchdog-next] watchdog: kill unref/ref ops
> 
> On 01/03/2016 03:32 AM, Tomas Winkler wrote:
> > ref/unref ops are not called at all so even marked them as deprecated
> > is misleading, we need to just drop the API.
> >
> One the other side, the functions are now no-ops, so they don't hurt either.
> Only reason for not dropping the functions as part of my series was that
> the mei watchdog code was starting to implement them, and I didn't want
> to create dependencies for that code. Maybe my thinking was too conservative.
> 
> > Signed-off-by: Tomas Winkler <[email protected]>
> 
> ... of course that is no concern anymore since this patch is from its
> maintainer.
> 
> Acked-by: Guenter Roeck <[email protected]>

Now I'm looking into the current code and one thing I do not understand , if 
the watchdog_core_data is holding
a pointer to wdd, who is responsible for wdd and who is holding the reference 
counter on that pointer.
If the underlying driver will release the wdd (for any reason) your code will 
read junk. 
I think wdd should not be a pointer here.

/*
 * struct watchdog_core_data - watchdog core internal data
 * @kref:       Reference count.
 * @cdev:       The watchdog's Character device.
 * @wdd:        Pointer to watchdog device.
 * @lock:       Lock for watchdog core.
 * @status:     Watchdog core internal status bits.
 */
struct watchdog_core_data {
        struct kref kref;
        struct cdev cdev;
        struct watchdog_device *wdd;
        struct mutex lock;
        unsigned long status;           /* Internal status bits */
#define _WDOG_DEV_OPEN          0       /* Opened ? */
#define _WDOG_ALLOW_RELEASE     1       /* Did we receive the magic char ? */
};

Thanks
Tomas 
--
To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to