[PATCH 063/196] kset: convert /sys/devices to use kset_create

Olof Johansson olof at lixom.net
Sun Jan 27 04:36:12 EST 2008

On Fri, Jan 25, 2008 at 09:24:54PM -0800, Greg KH wrote:
> On Fri, Jan 25, 2008 at 09:40:55PM -0600, Olof Johansson wrote:
> > On Thu, Jan 24, 2008 at 11:10:01PM -0800, Greg Kroah-Hartman wrote:
> > > Dynamically create the kset instead of declaring it statically.  We also
> > > rename devices_subsys to devices_kset to catch all users of the
> > > variable.
> > 
> > Guess what, you broke powerpc again!
> I did this ON PURPOSE!!!
> The linux-kernel archives hold the details, and I was told by the PPC64
> IBM people that they would fix this properly for 2.6.25, and not to hold
> back on my changes.  This has been known for many months now.

Yeah, my bad. :( I thought this was new, but it was just not exposed by
my scripts because of the EHEA build errors (they were actual compile
errors, while this was a link error, so it never go this far). That's
why I didn't see it in -rc8-mm1 and thought it was new.

> > -extern struct kset devices_subsys; /* needed for vio_find_name() */
> > +extern struct kset *devices_kset; /* needed for vio_find_name() */
> No, this just papers over the real problem here.  For some reason, the
> vio code thinks it is acceptable to walk the whole device tree and match
> by a name and just assume that they got the correct device.  You call
> this "enterprise grade"?  :)
> You need to just put your device on a real bus, and then just walk the
> bus.  That's the ONLY way you can guarantee the proper name will return
> what you want, and you get the pointer that you really think you are
> getting.

Hmm, they are already on a bus. Odd, must be done like this for legacy


> So no, I'm going to leave the build broken for this code, because that
> is what it really is.
> Please fix it correctly.

Alright, I'll leave that to people who care about vio and can test the
proper fix. After a quick glance it looks like it should be easy to use
bus_find_device() for it instead.


More information about the Linuxppc-dev mailing list