lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20150901175319.GA30006@roeck-us.net>
Date:	Tue, 1 Sep 2015 10:53:19 -0700
From:	Guenter Roeck <linux@...ck-us.net>
To:	Justin Chen <justinpopo6@...il.com>
Cc:	linux-kernel@...r.kernel.org, wim@...ana.be,
	linux-watchdog@...r.kernel.org,
	bcm-kernel-feedback-list@...adcom.com
Subject: Re: [PATCH] watchdog_dev: Use device tree alias for naming watchdogs

On Tue, Sep 01, 2015 at 10:20:36AM -0700, Justin Chen wrote:
> On Sat, Aug 29, 2015 at 2:53 AM, Guenter Roeck <linux@...ck-us.net> wrote:
> > On 08/28/2015 02:58 PM, Justin Chen wrote:
> >>
> >> Currently there is no way to easily differentiate multiple
> >> watchdog devices. The watchdogs are named by the order they
> >> are probed.
> >> 1st probed watchdog: /dev/watchdog0
> >> 2nd probed watchdog: /dev/watchdog1
> >> ...
> >>
> >> This change uses the alias of the watchdog device node for
> >> the name of the watchdog.
> >> aliases {
> >>         watchdog0 = "/...../...."
> >>         watchdog3 = "/..../....."
> >>         watchdog2 = "/..../....."
> >>         ...
> >> }
> >>
> >> This will translate to...
> >> /dev/watchdog0
> >> /dev/watchdog3
> >> /dev/watchdog2
> >>
> >> Signed-off-by: Justin Chen <justinpopo6@...il.com>
> >
> >
> > Interesting idea. Checking through other subsystems, many others do the
> > same,
> > so it makes sense to use that mechanism.
> >
> > However, the id assignment should be in the calling code, in
> > __watchdog_register_device,
> > to avoid that another id, possibly conflicting, is assigned through the
> ida
> > mechanism.
> >
> > This is a bit more complicated than it looks like to ensure correct id
> > assignment.
> > Have a look into the i2c code to see how it is handled. Essentially we
> must
> > pass
> > the requested number to ida_simple_get().
> >
> > Thanks,
> > Guenter
> 
> Ok that makes sense. I will put a wrapper function around ida_simple_get()
> that will request a specific number, if that fails then do a normal request.
> Something like this...
> 
> ret = of_alias_get_id(....)
> 
> id = ida_simple_get(&watchdog_ida, ret, ret, GFP_KERNEL);
> 
				ret, ret + 1

but something like
	ret =  of_alias_get_id(...);
	if (ret >= 0)
		id = ida_simple_get(&watchdog_ida, ret, ret + 1, GFP_KERNEL);
	else
		id = ida_simple_get(&watchdog_ida, 0, MAX_DOGS, GFP_KERNEL);
	if (id < 0)
		return id;

would be better. Passing 'ret' directly would not work, because
ida_simple_get() expects an unsigned range as parameters, and
of_alias_get_id() can return a negative error code.

Thanks,
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ