linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Brownell <david-b@pacbell.net>
To: linux-hotplug@vger.kernel.org
Subject: Re: hotplug events on USB ethernet adapters
Date: Fri, 14 Jun 2002 04:22:25 +0000	[thread overview]
Message-ID: <marc-linux-hotplug-102402854232478@msgid-missing> (raw)
In-Reply-To: <marc-linux-hotplug-102402435730401@msgid-missing>

> I have a LinkSys Ethernet USB adapter
> When I plug it in, I get two hotplug events, one for net and one for usb
> Is there an easy way to associate these two events?

Not really.  Why would you want that?


> What I mean is, 
> 
>  is there a way for the /etc/hotplug/usb agent (and thus the
>  /etc/hotplug/usb/pegasus) to know know which ethN INTERFACE is going
>  to correspond to this device,

No, since at the time the usb level event is reported the network
driver may not even have been loaded ... and it's that driver which
chooses the "ethN" prefix.  Since other drivers might be getting
loaded concurrently, even if you were to guess about prefix "eth",
you couldn't guess the value of "N".


>  and/or else
> 
>  is there a way for the /etc/hotplug/net.agent to know that this
>  interface is a USB device, and what PRODUCT, TYPE, INTERFACE, and
>  DEVICE & DEVFS it is?

No, but it can get part way there in 2.5 ...

At least on the 2.5 kernels, "ethtool -i eth0" will give you some
"bus-info" that's identifies the physical location of the device.
It's what the usb_make_path() call returns.

It's a string like "usb-00:0f.1-3.2" indicating first that it's
USB, then that it's the bus with name/serial "00:0f.1" (which in
this case is a PCI slot), then that it's connected to port 3 on
the root hub, and port 2 on the hub connected there.  That's a
stable name, it won't change unless/until you re-cable things.
Which means that it's possible to set up persistent configurations
over USB.  (There are non-USB "bus-info" values too, like for pci.)


I've thought that it would be useful to have the hotplug agent
report the usb_make_path() information, using some other variable.
Likewise, to have USBFS report those strings through some ioctl
on the device.  (You can reconstruct it, but it's awkward and
expensive and requires r/w access to most devices on the same
bus, so I'd not encourage folk to do that.)

- Dave



_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

      reply	other threads:[~2002-06-14  4:22 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-06-14  3:11 hotplug events on USB ethernet adapters Mark Atwood
2002-06-14  4:22 ` David Brownell [this message]

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=marc-linux-hotplug-102402854232478@msgid-missing \
    --to=david-b@pacbell.net \
    --cc=linux-hotplug@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).