From: Kay Sievers <kay.sievers@vrfy.org>
To: linux-hotplug@vger.kernel.org
Subject: Re: Udev rule for HSDPA modem
Date: Wed, 03 Dec 2008 15:11:29 +0000 [thread overview]
Message-ID: <1228317089.6977.16.camel@nga> (raw)
In-Reply-To: <bed87e0b812045212a08a0c9ef4a06b2.squirrel@kone.netland.fin>
[-- Attachment #1: Type: text/plain, Size: 3279 bytes --]
On Wed, 2008-12-03 at 13:12 +0100, Kay Sievers wrote:
> On Wed, Dec 3, 2008 at 10:27, Kay Sievers <kay.sievers@vrfy.org> wrote:
> > On Wed, Dec 3, 2008 at 07:45, Greg KH <greg@kroah.com> wrote:
> >> On Sun, Nov 30, 2008 at 06:21:11AM +0100, Kay Sievers wrote:
> >>> On Sat, Nov 29, 2008 at 18:37, Greg KH <greg@kroah.com> wrote:
> >>> > On Sat, Nov 29, 2008 at 10:00:59AM +0200, Jar wrote:
> >>> >> Greg KH wrote:
> >>> >>> HAL contains a list of these modems and a mapping of each port to what
> >>> >>> it does based on the specific device.
> >>> >>> Try using that instead of udev specific rules for your accessed to the
> >>> >>> modem, it will work much better.
> >>> >>
> >>> >> Thanks for your reply! Does HAL require that I have desktop installed, this
> >>> >> is my home "server" machine without X? Do you have any starting point or
> >>> >> where to learn more how to do this with HAL.
> >>> >
> >>> > I do not think HAL requires X. Try asking on your distro mailing list
> >>> > for how they have incorporated HAL into the releases you are using.
> >>>
> >>> It might get pretty complicated to use D-Bus/HAL for simple setups,
> >>> and rather static configurations like this. NetworkManager handles
> >>> that, and we will even get modem-probing soon, but in cases like this
> >>> it might be easier to have a simple - not very flexible - but working
> >>> solution.
> >>>
> >>> Maybe we can have an "index" sysfs file at the serial device, which
> >>> carries the instance number, per usb device? This would allow us to
> >>> create persistent links which do not depend on the kernel device
> >>> enumeration across multiple device.
> >>>
> >>> We did the same for v4l devices recently:
> >>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=539a7555b31e65e66fb84c881d07d2bf18c974d0
> >>>
> >>> Greg, what do you think?
> >>
> >> Don't we already have something like this today (the "ports" on an
> >> individual usb-serial device)? Or do we just need to export that a bit
> >> better?
> >
> > Yeah, maybe that works already. I don't have such a device.
>
> Ok, I found one. You mean "port_number", right? But unfortunately it
> looks pretty useless in this case. :)
>
> $ grep . /sys/bus/usb-serial/devices/*/port_number
> /sys/bus/usb-serial/devices/ttyUSB1/port_number:0
> /sys/bus/usb-serial/devices/ttyUSB2/port_number:0
>
> They would only be not "0" if the serial lines would be on the same
> usb interface?
>
> We would need a per-device enumeration, but that's nothing the
> usb-serial stuff knows/cares about if we have different usb
> interfaces, right?
Greg, do you have a usb multi-port serial card? Can you possibly give
this a try, and show us "tree /dev/serial"?
I have this here now for my "simple" devices:
/dev/serial
`-- by-id
|-- usb-067b_2303-serial-if00-port0 -> ../../ttyUSB0
|-- usb-HUAWEI_Technology_HUAWEI_Mobile-serial-if00-port0 -> ../../ttyUSB1
`-- usb-HUAWEI_Technology_HUAWEI_Mobile-serial-if01-port0 -> ../../ttyUSB2
If we can make that work as expected, I'll look into by-path/, so we can
have identical devices properly identified, if needed. Then we can check
how we should finally name all that, and possibly add that stuff to the
default rule set.
Thanks,
Kay
[-- Attachment #2: Type: text/plain, Size: 625 bytes --]
# do not edit this file, it will be overwritten on update
ACTION!="add|change", GOTO="persistent_serial_end"
SUBSYSTEM!="tty", GOTO="persistent_serial_end"
KERNEL!="ttyUSB[0-9]*", GOTO="persistent_serial_end"
IMPORT="usb_id --export"
ENV{ID_SERIAL}=="", GOTO="persistent_serial_end"
SUBSYSTEMS=="usb-serial", ENV{ID_PORT}="$attr{port_number}"
ENV{ID_PORT}=="", GOTO="persistent_serial_end"
SUBSYSTEMS=="usb", ENV{ID_IFACE}="$attr{bInterfaceNumber}"
ENV{ID_IFACE}=="", GOTO="persistent_serial_end"
SYMLINK+="serial/by-id/$env{ID_BUS}-$env{ID_SERIAL}-serial-if$env{ID_IFACE}-port$env{ID_PORT}"
LABEL="persistent_serial_end"
next prev parent reply other threads:[~2008-12-03 15:11 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-28 17:56 Udev rule for HSDPA modem Jar
2008-11-28 18:51 ` Greg KH
2008-11-29 8:00 ` Jar
2008-11-29 17:37 ` Greg KH
2008-11-30 5:21 ` Kay Sievers
2008-12-03 6:45 ` Greg KH
2008-12-03 9:27 ` Kay Sievers
2008-12-03 12:12 ` Kay Sievers
2008-12-03 15:11 ` Kay Sievers [this message]
2008-12-03 17:06 ` Karl O. Pinc
2008-12-03 17:37 ` Kay Sievers
2008-12-03 18:49 ` Karl O. Pinc
2008-12-03 23:10 ` Greg KH
2008-12-03 23:54 ` Kay Sievers
2008-12-04 0:04 ` Greg KH
2008-12-04 0:12 ` Kay Sievers
2008-12-04 0:40 ` Greg KH
2008-12-04 1:14 ` Kay Sievers
2008-12-04 6:28 ` Jar
2008-12-04 7:23 ` Kay Sievers
2008-12-04 14:22 ` Jar
2008-12-04 15:27 ` Karl O. Pinc
2008-12-04 18:56 ` Greg KH
2008-12-04 19:11 ` Greg KH
2008-12-05 2:53 ` Kay Sievers
2008-12-05 4:54 ` Karl O. Pinc
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=1228317089.6977.16.camel@nga \
--to=kay.sievers@vrfy.org \
--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).