linux-kernel - Re: [PATCH] gpiolib: Allow user-selection

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:	Thu, 3 Jul 2008 14:28:00 -0700
From:	David Brownell <david-b@...bell.net>
To:	Greg KH <greg@...ah.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Michael Buesch <mb@...sch.de>, sfr@...b.auug.org.au,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] gpiolib: Allow user-selection

On Thursday 03 July 2008, Greg KH wrote:
> On Wed, Jul 02, 2008 at 10:41:27PM -0700, David Brownell wrote:
> > The new "-next" process is still working out.  Backwards-incompatible
> > changes will *always* make problems.  In this case there seem to
> > have been three such changes:
> > 
> > 	- device_create() vanishing, even for users which did the
> > 	  locking correctly ... this was at least something of a
> > 	  graceful migration, although it would have been better
> > 	  if it were deprecated first.  Change can work against
> > 	  the current (2.6.26) code base.
> 
> device_create() did disappear in -next, but when it goes to Linus it
> will not, it will come back as a #define and everything will be
> converted back.  That was to catch the build errors when I audited the
> whole tree.  The -rc1 merge cycle will handle this properly.

Hmm, that's a surprise.  Any reason that's not in "-next" already?


> > 	- class.devices vanishing ... what I really needed was
> > 	  more of a "is this class initialized yet" call, so
> > 	  testing for class->devices.next non-null can be replaced
> > 	  by a test for class->p non-null.  (Or maybe this should
> > 	  be viewed as needing a "real" driver model call, so that
> > 	  code which must run before driver model init can more
> > 	  easily cooperate with driver model stuff that has to
> > 	  run much later, after the guts are initialized.)
> 
> If you need such a function, please let me know and I can provide it, I
> was not aware of anyone using class.devices, it is an
> internal-to-the-driver-core field, and has moved private.

When the fields are there, it's hard to say what's "internal"
in the absense of comments ... :)

The scenario is that gpios sometimes get initialized very early,
as part of board setup before kmalloc or irqs work, so when they
get registered sometimes there's work left over for later.  All
that's needed is a predicate to test whether that class can be
used as a parameter to stuff like device_create_drvdata() and
sysfs_create_group().


> > 	- Extra parameter to class_find_device().  This could
> > 	  have been done in a backwards-compatible manner, like
> > 	  device_create() was, but ... it wasn't.
> 
> This was simpler as there were less users of this function.  And the
> whole tree was fixed up.  If there are trees on top of -next that I
> can't see, that's pretty hard for me to fix :)

This was in the MM tree with other GPIO patches.

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