All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Linux Kernel list <linux-kernel@vger.kernel.org>
Subject: Re: bus_id collisions
Date: Mon, 20 Nov 2006 22:41:22 -0800	[thread overview]
Message-ID: <20061121064122.GA10510@kroah.com> (raw)
In-Reply-To: <1164081736.8207.14.camel@localhost.localdomain>

On Tue, Nov 21, 2006 at 03:02:16PM +1100, Benjamin Herrenschmidt wrote:
> Hi Greg !
> 
> It occurs to me (after some trouble I had with custom bus types) that
> this comment is incorrect in device.h, in the definition of struct
> device :
> 
>         char    bus_id[BUS_ID_SIZE];    /* position on parent bus */
> 
> As the bus_id needs to be unique for a given bus_type, not only under a
> given parent, due to the symlinks in /sys/bus/<bus_type>/.

Yes, sorry, that comment is _very_ old...

> This has caused me some trouble with of_platform devices, which are
> sort-of platform devices but linked to the Open Firmware device-tree, as
> I generate their names based on the nodes in the tree which need not be
> unique as long as they are unique under a given parent.
> 
> I've worked around it, but I though the comment might need to be
> clarified.

Ok.

> Also, I don't suppose you have any plan to move away from the bus_id
> being a fixed size array inside struct device ?

No, I had not heard of anyone having any problems with the size of it.
We could just do it like the kobject does, and have a function to set it
and handle the pointer vs. array issue there if you _really_ need a
bigger size.

> I would very much like to be able to have larger names ... Among
> others, in order to handle the above problem, I tend to include the
> fully translated 64 bits address of the device in the name :-)
> (Hopefully, it's generally smaller and I don't have leading zero's but
> still, I have little room left for the device name which is annoying).

Oh, that's a very annoying bus id, but I guess it's legal.

I'll poke around and see if I can make it bigger.  You don't want it
bigger for static 'struct device' types, right?

thanks,

greg k-h

  parent reply	other threads:[~2006-11-21  6:42 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-21  4:02 bus_id collisions Benjamin Herrenschmidt
2006-11-21  6:13 ` David Miller
2006-11-21  6:23   ` Benjamin Herrenschmidt
2006-11-21  6:41 ` Greg KH [this message]
2006-11-21  6:49   ` Benjamin Herrenschmidt
2006-11-22  4:38     ` Kumar Gala

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20061121064122.GA10510@kroah.com \
    --to=greg@kroah.com \
    --cc=benh@kernel.crashing.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.