Fix Firmware class name collision

[Kay Sievers]

On Fri, 2007-12-14 at 22:39 -0800, Greg KH wrote:
> On Sat, Dec 15, 2007 at 05:14:29PM +1100, Benjamin Herrenschmidt wrote:
> > 
> > On Fri, 2007-12-14 at 14:40 -0800, Greg KH wrote:
> > > On Tue, Dec 04, 2007 at 07:28:00PM -0600, Timur Tabi wrote:
> > > > Scott Wood wrote:
> > > >
> > > >> The physical address certainly is useful when you have more than one 
> > > >> device of the same name.
> > > >
> > > > What I meant was that the physical address isn't helpful by itself.
> > > >
> > > >> So then you'd get "firmware-ucc.e01024".  What if there's another ucc at  
> > > >> e0102480?  For devices with longer names, you'd have even less precision 
> > > >> in the address.
> > > >
> > > > Maybe we need to consider a more sophisticated algorithm, one that 
> > > > guarantees that the device name in its entirety is preserved?  Either that, 
> > > > or replace the physical address with something shorter, like the offset to 
> > > > the root node only?  That way, ucc.e0102400 because just ucc.2400.
> > > 
> > > You should do something :)
> > > 
> > > In the near future (2.6.26) there will not be a limit on the size of the
> > > file name, so we should not have this problem anymore.
> > 
> > Not even .25 ? damn ! Any way that fix can be fastracked ? This
> > limitation has been a major PITA for some time now (this is just -one-
> > example where it gets in the way).
> 
> I'll let Kay answer that, last he said, it involves a _lot_ of changes
> throughout the kernel :(

The current patch gets rid of bus_id and uses the dynamic kobject_name
directly all over the place. It's huge, because the current code expects
a static array and uses strncpy/snprintf all over the place.

I'm currently waiting for the new kobject api to finish, before I update
the patch, not sure if we will make it in time for .25.

Kay