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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 10 Mar 2008 16:39:08 -0800
From:	David Brownell <david-b@...bell.net>
To:	Liam Girdwood <lg@...nsource.wolfsonmicro.com>
Cc:	linux-arm-kernel@...ts.arm.linux.org.uk,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [UPDATED v3][PATCH 1/7] regulator: consumer interface

On Sunday 09 March 2008, Liam Girdwood wrote:
> 
> > > +struct regulator *__must_check regulator_get(struct device *dev,
> > > +                                            const char *id);
> > 
> > The semantics of "id" and "dev" are unspecified in this patch,
> > so this isn't a good definition of the consumer interface!
> > 
> 
> 'id' is really the regulator name and will be renamed in the next patch.

Still not helping.  How would a driver know what names to use?
Are those names globally scoped, or local to the device?

Again, "id" and "dev" are unspecified.  I can maybe guess that
you're trying to make this look like <linux/clk.h> ... except
the clock API includes kernel doc in that header.

I *strongly* think new interfaces should not be provided without
documentation... but that's what this patch does.


> > Plus, that works more like a "lookup" than a "get" ... the
> > usual convention is that "get" and "put" update refcounts.
> > But I think I see an assumption here that a regulator may
> > have only one user...
> 
> A regulator only has one user as it's used to store some device specific
> power data. However, a regulator_dev has many users. I'll add a refcount
> on get/put.

I'm still not following.  If there's only one user, why would
you need refcounting?  If your model here is the clock API,
then you should support multiple users ... and then refcounting
is very appropriate.

- Dave


--
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