On Thu, 2010-04-29 at 09:53 +0200, toabctl wrote:At the moment we don't probe platform devices for a few reasons, one
> 2010/4/28 Dan Williams <dcbw redhat com>
> On Wed, 2010-04-28 at 09:37 +0200, toabctl wrote:
> > 1) How does network-manager detect that the modem is
> connected? Or how
> > can i tell networkmanager on which port the modem is
> attached? I use a
> > rs232<->usb adapter so the port is /dev/ttyUSB0 .
> ModemManager uses udev for device detection. It listens for
> udev events
> (which you can also listen for with udevmonitor) and when it
> receives a
> notification of a new serial port, it will inspect that port
> and attempt
> to probe it.
> How does ModemManager probe the port? I want to use modem manager also
> with a rs232 device and there are no uevents because rs232 has no
> hotplug. but i could emit a uevent "by hand".
that (a) the code isn't there, and (b) older devices like those
connected to platform serial ports on normal PCs often get upset
precisely because they are older and either aren't modems, or aren't
standards compliant in any way.
But check out this commit:
Author: Dan Williams <dcbw redhat com>
Date: Thu Apr 29 12:17:56 2010 -0700
core: add platform device support and whitelist
and see if that works for you. It uses a whitelist for platform
drivers. Let me know!
> The information about the device ( /dev/ttyS1 ):
> # udevadm info --query=all -n /dev/ttyS1
> P: /devices/platform/atmel_usart.1/tty/ttyS1
> N: ttyS1
> S: char/4:65
> E: UDEV_LOG=3
> E: DEVPATH=/devices/platform/atmel_usart.1/tty/ttyS1
> E: MAJOR=4
> E: MINOR=65
> E: DEVNAME=/dev/ttyS1
> E: SUBSYSTEM=tty
> E: DEVLINKS=/dev/char/4:65
> # udevadm info --query=all -n /dev/ttyS1 --attribute-walk
> looking at device '/devices/platform/atmel_usart.1/tty/ttyS1':
> looking at parent device '/devices/platform/atmel_usart.1':
> looking at parent device '/devices/platform':
> How can i use this port with ModemManager? The modem is connected and
> AT-Commands works.
> There are a number of requirements of the port though; it
> verifies that the kernel has assigned a driver name to the
> port or one
> of the port's parents, and it attempts to grab the port's
> device. Given that it's USB, it *should* work. But if it
> doesn't, and
> you have a chance to grab the ModemManager source , there's
> a tool
> called 'lsudev' in the test/ directory that can give us an
> idea of the
> udev-provided information of the device.
> i guess 'lsudev' does the same as my 2 commands with 'udevadm', right?
> or does 'lsudev' something more special?
> > 2) How does the connection-config looks like?
> ModemManager is just a tool to control the modem, it doesn't
> store any
> configuration about it. The configuration is provided by a
> program that
> tells ModemManager what to do. There are a few ways to do
> NetworkManager provides a general modem control solution, but
> you can
> also write your own app that uses D-Bus to tell ModemManager
> what to do
> with the modem. See test/mm-test.py for a short example of
> how to use
> python and D-Bus to make MM connect the modem and get
> information out of
> ah. that's great. i need to control the modem over a web-interface so
> no nm-applet available.