From: Greg KH <greg@kroah.com>
To: Martyn Welch <martyn.welch@ge.com>
Cc: gregkh@suse.de, cota@braap.org, devel@driverdev.osuosl.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/6] staging: vme: allow explicit assignment of bus numbers
Date: Tue, 23 Aug 2011 15:06:59 -0700 [thread overview]
Message-ID: <20110823220659.GA15721@kroah.com> (raw)
In-Reply-To: <4E427E89.8010700@ge.com>
On Wed, Aug 10, 2011 at 01:50:17PM +0100, Martyn Welch wrote:
> On 10/08/11 11:41, Manohar Vanga wrote:
> > Hey Martyn,
> >
> >> I'm sorry, I'm still simply not convinced by this patch:
> >>
> >> 1) For a single bus driver (i.e. in the situation where we have 2 bridges of
> >> the same type), the numbering of the buses is still dependent on the order
> >> that they are found in the scan.
> >
> > Yes this is still a bug. But this patch doesn't address this case.
> >
> >> 2) If the bridge drivers are loaded as modules, I have a feeling they will be
> >> loaded sequentially and therefore the order of the bridges would only change
> >> if the order of the loading of the drivers changed.
> >
> > And this is a major problem when it comes to multiple bridges of differing
> > types. What I'm saying is that this patch simply fixes this one problematic
> > case. We can move this out as soon as we have a more robust implementation.
> >
> > As of now however, I think applying this is useful as we have a decent
> > workaround to the problem. If you want I can make the fact of it being
> > applicable only to cases with differing bridges explicit in the commit
> > message.
> >
>
> The problem is, I'm not convinced that this is the correct approach to take. I
> think this should be parsed from sysfs dynamically (which may require some
> work). I shall use the ethernet devices on my machine as an example:
>
> I have 2 ethernet devices (and lo) on my machine:
>
> $ ls /sys/class/net/
> eth0 eth1 lo
> $
>
> These are symlinks and I can quite quickly find out which each of these
> devices in (based on topology):
> $ ls -l /sys/class/net/
> total 0
> lrwxrwxrwx 1 root root 0 2011-08-10 11:56 eth0 ->
> ../../devices/pci0000:00/0000:00:19.0/net/eth0
> lrwxrwxrwx 1 root root 0 2011-08-10 11:56 eth1 ->
> ../../devices/pci0000:00/0000:00:1c.1/0000:03:00.0/net/eth1
> lrwxrwxrwx 1 root root 0 2011-08-10 11:56 lo -> ../../devices/virtual/net/lo
> $
>
> I'd think that this contains the information that you have in the config file
> (based on the previous discussion we had) and would allow you to map the bus
> numbering after booting.
>
> To do this, I think we need to register a class called "vme", I guess in
> vme_init() and add a call to class_device_register in vme_register_bridge and
> a call to class_device_unregister in vme_unregister_bridge.
>
> Greg: Is that right?
Yes.
> I'm really not convinced that the solution presented in this patch is suitable
> for inclusion upstream.
I agree. Bus numbers are dynamic and should NEVER be depended on by
userspace to be static and unchanging on reboots.
thanks,
greg k-h
next prev parent reply other threads:[~2011-08-23 22:16 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-10 9:33 [PATCH 0/6] [RESEND] VME framework fixes Manohar Vanga
2011-08-10 9:33 ` [PATCH 1/6] staging: vme: allow explicit assignment of bus numbers Manohar Vanga
2011-08-10 10:02 ` Martyn Welch
2011-08-10 10:41 ` Manohar Vanga
2011-08-10 12:50 ` Martyn Welch
2011-08-23 22:06 ` Greg KH [this message]
2011-08-10 9:33 ` [PATCH 2/6] staging: vme: make [alloc|free]_consistent bridge specific Manohar Vanga
2011-08-10 10:04 ` Martyn Welch
2011-08-10 13:24 ` Dan Carpenter
2011-08-10 13:12 ` Joe Perches
2011-08-10 13:34 ` Martyn Welch
2011-08-10 13:51 ` Joe Perches
2011-08-10 13:55 ` Martyn Welch
2011-08-10 14:30 ` Joe Perches
2011-08-10 14:33 ` Martyn Welch
2011-08-10 9:33 ` [PATCH 3/6] staging: vme: keep track of registered buses Manohar Vanga
2011-08-10 10:06 ` Martyn Welch
2011-08-10 9:33 ` [PATCH 4/6] staging: vme: add functions for bridge module refcounting Manohar Vanga
2011-08-10 10:09 ` Martyn Welch
2011-08-10 19:14 ` Emilio G. Cota
2011-08-10 9:33 ` [PATCH 5/6] staging: vme: add struct vme_dev for VME devices Manohar Vanga
2011-08-10 10:14 ` Martyn Welch
2011-08-10 10:33 ` Manohar Vanga
2011-08-10 9:33 ` [PATCH 6/6] staging: vme: make match() driver specific to improve non-VME64x support Manohar Vanga
2011-08-10 10:18 ` Martyn Welch
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=20110823220659.GA15721@kroah.com \
--to=greg@kroah.com \
--cc=cota@braap.org \
--cc=devel@driverdev.osuosl.org \
--cc=gregkh@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=martyn.welch@ge.com \
/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.