gmane.linux.hotplug.devel

[PATCH V2] rules: Limit USB autosuspend on USB HID devices

Matthew Garrett — 2012-05-25T14:27:25

Some USB ports on external hubs may be reported as "fixed". We only want
to auto-enable this on ports that are internal to the machine, so check
the parent state as well.
---

Sorry, screwed up the label name on the first version.

 rules/42-usb-hid-pm.rules |    6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/rules/42-usb-hid-pm.rules b/rules/42-usb-hid-pm.rules
index d5d5897..9e5f59f 100644
--- a/rules/42-usb-hid-pm.rules
+++ b/rules/42-usb-hid-pm.rules
< at >< at > -46,4 +46,10 < at >< at > ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="04b3", ATTR{idProduct}=="4012
 ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="14dd", ATTR{idProduct}="0002", TEST=="power/control", ATTR{power/control}="auto"
 
 # USB HID devices that are internal to the machine should also be safe to autosuspend
+
+ACTION=="add", SUBSYSTEM=="usb", SUBSYSTEMS=="usb", ATTRS{removable}=="removable", GOTO="usb_hid_pm_end"
+ACTION=="add", SUBSYSTEM=="usb", SUBSYSTEMS=="usb", ATTRS{removable}=="unknown", GOTO="usb_hid_pm_end"        
+
 ACTION=="ad

[PATCH] rules: Limit USB autosuspend on USB HID devices

Matthew Garrett — 2012-05-25T12:01:58

Some USB ports on external hubs may be reported as "fixed". We only want
to auto-enable this on ports that are internal to the machine, so check
the parent state as well.
---
 rules/42-usb-hid-pm.rules |    6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/rules/42-usb-hid-pm.rules b/rules/42-usb-hid-pm.rules
index d5d5897..fc44b94 100644
--- a/rules/42-usb-hid-pm.rules
+++ b/rules/42-usb-hid-pm.rules
< at >< at > -46,4 +46,10 < at >< at > ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="04b3", ATTR{idProduct}=="4012
 ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="14dd", ATTR{idProduct}="0002", TEST=="power/control", ATTR{power/control}="auto"
 
 # USB HID devices that are internal to the machine should also be safe to autosuspend
+
+ACTION=="add", SUBSYSTEM=="usb", SUBSYSTEMS=="usb", ATTRS{removable}=="removable", GOTO="usb_hid_pm_end"
+ACTION=="add", SUBSYSTEM=="usb", SUBSYSTEMS=="usb", ATTRS{removable}=="unknown", GOTO="usb_hid_pm_end"        
+
 ACTION=="add", SUBSYSTEM=="usb", ATTR{bInterfaceClass}=="03", ATTRS{

systemd-183

Bruce Dubbs — 2012-05-24T19:36:36

I see that systemd-183 is out in the 
http://www.freedesktop.org/software/systemd/ repository.

My understanding is that this version of systemd has udev included.

I've looked through the NEWS, README, and ./configure --help.

How do I build udev without systemd?  Failing that, how do I install 
just udev without systend?

Or will there be a separate udev distribution?

   -- Bruce Dubbs
      Linux From Scratch
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

bus id match

Michal Filka — 2012-05-22T13:07:14

Hi,

I've problem with following rule (simplified as much as possible):

# replaced 70-persistent-net.rules
SUBSYSTEM=="net", KERNELS="0000:00:19.0", NAME="eth1"

#  udevadm test --action=add /sys/class/net/eth0
(snip)
rename_netif: changing net interface name from 'eth0' to 'eth1'
rename_netif: error changing net interface name eth0 to eth1: Device or  
resource busy
(snip)
UDEV_LOG=6
DEVPATH=/devices/pci0000:00/0000:00:19.0/net/eth0
INTERFACE=eth0
IFINDEX=2
ACTION=add
SUBSYSTEM=net
ID_VENDOR_FROM_DATABASE=Intel Corporation
ID_MODEL_FROM_DATABASE=82566DC Gigabit Network Connection
ID_BUS=pci
ID_VENDOR_ID=0x8086
ID_MODEL_ID=0x104b
ID_MM_CANDIDATE=1
SYSTEMD_ALIAS=/sys/subsystem/net/devices/eth1
TAGS=:systemd:

So, the device is named correctly (eth1), but what about that rename_netif  
errors? Is that a problem?


Michal Filka
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordom

udev, net device alias

Michal Filka — 2012-05-22T10:08:58

Hi,

is it possible to create an alias for an ethernet device using udev rules?  
E.g. to have eth0 accessible even as "eth0" and "eth-alias" at the same  
time.

Thanks for info
Michal Filka
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Missing ID_BUS, ID_TYPE

John Frankish — 2012-05-21T05:48:01

Ref (udev-173)

$ udevadm info -q env -n /dev/sda
DEVPATH=/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda
MAJOR=8
MINOR=0
DEVNAME=/dev/sda
DEVTYPE=disk
SUBSYSTEM=block
ID_PATH=pci-0000:00:1f.2-scsi-0:0:0:0
ID_PATH_TAG=pci-0000_00_1f_2-scsi-0_0_0_0
DEVLINKS=/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0

I would expect something like "ID_BUS=ata" and "ID_TYPE=disk" to be returned, but they are not.

What controls the reporting of ID_BUS and ID_TYPE?

Regards
John
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

modprobe.d question.

F. Heitkamp — 2012-05-03T12:22:47

I have a module that I want to have installed during the boot process 
(fbcon) but I can't figure out what the standard practice would be to do it.

I am still using SYSV init as well.

The brute force approach would be to just write a shell script that 
executes during the boot process.

 From what I understand reading docs what adding install fbcon modprobe 
-v fbcon  to  a conf file in modprobe.d  (say I called it fbcon.conf ) 
would do is if the hot-plugging needed fbcon it would use fbcon.conf 
instead.

I am most familiar with debian and there is a file called /etc/modules 
that lists modules to be installed during boot, but I think the magic of 
modprobe is not used so the dependencies would not get included.

I am not using a initial ram disk.

This is on a "linux from scratch" like system, but not LFS.

Any corrections or thoughts?

Fred



--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://

[PATCH] fxload: Add support for loading FX3 RAM

Steven J. Magnani — 2012-04-27T20:20:04

Adds the ability to load a single-stage Cypress ".img" file
to FX3 RAM. The tweaks Cypress made to the download protocol
to support the FX3 are described here:

  http://www.cypress.com/?app=forum&id=167&rID=53996

The FX3 .img format is described in the FX3 Programmer's Manual,
provided with the EZ-USB FX3 Software Development Kit.

Signed-off-by: Steven J. Magnani <steve< at >digidescorp.com>
---
diff -uprN fxload-cvs/ezusb.c fxload-fx3/ezusb.c
--- fxload-cvs/ezusb.c2012-04-27 12:47:44.856752994 -0500
+++ fxload-fx3/ezusb.c2012-04-27 14:45:50.083897780 -0500
< at >< at > -2,6 +2,7 < at >< at >
  * Copyright (c) 2001 Stephen Williams (steve< at >icarus.com)
  * Copyright (c) 2001-2002 David Brownell (dbrownell< at >users.sourceforge.net)
  * Copyright (c) 2008 Roger Williams (rawqux< at >users.sourceforge.net)
+ * Copyright (c) 2012 Steve Magnani (steve< at >digidescorp.com)
  *
  *    This source code is free software; you can redistribute it
  *    and/or modify it in source code form under the terms of the GNU
< at >< at > -22,10 +23,13 < at >< at >
 
 # include  <s

udev missing events?

Jim Paris — 2012-04-22T04:36:55

(cc'd Eric and Milan because 5f71a296 and ebf4127c might be related)

I'm trying to track down a problem that started with virt-manager not
being able to connect to libvirtd.  Long story short, the problem is
that "udevadm settle" is timing out, with no events in the udev queue.

(I know it's bad for libvirt to rely on "udevadm settle", but it seems
that this is exposing some other problem).

This is with 3.2.14 from Debian.

I can trigger the problem easily by just starting libvirtd and killing
it.  Then, the counters are stuck here:

  # cat /sys/kernel/uevent_seqnum
  13593
  # od -t d2 /dev/.udev/queue.bin | head -1
  0000000  13592

During the libvirtd startup, I ran "udevadm monitor", which seems to
indicate that 13593 never made it to udev:

 # udevadm monitor --kernel --property
  monitor will print the received events for:
  KERNEL - the kernel uevent
  
  KERNEL[537903.765581] add      /devices/virtual/net/lo/queues/rx-0 (queues)
  ACTION=add
  DEVPATH=/devices/virtual/net/lo/queues/rx-0
  SEQNUM=1

"udevadm info --attribute-walk --path=/block/sda" doesn't show parents

Chris Friesen — 2012-04-18T21:42:59

I have a 2.6.34.10-based kernel with udev-161 (also tested with udevadm from udev-173).

When I run "udevadm info --attribute-walk --path=/block/sda" it just shows the device
itself, and doesn't walk the whole chain showing the parents.

Is there anything I can do, or am I caught with a kernel that isn't properly supported?
I'm not subscribed to the hotplug list, so cc'ing me would be appreciated.


I don't know what's causing the problem, but I find it suspicious that /sys/block/sda
is a directory rather than a symlink like it is on my 2.6.35.14 laptop.  I'm poking
around in the udevadm code now.


Some possibly-useful information:


root< at >typhoon-base-unit0:/root> udevadm info --attribute-walk --path=/block/sda

Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single par

/dev/shm and /dev/pts not been created by devtmpfs or udev

F. Heitkamp — 2012-04-18T12:41:29

I am using kernel 3.3.2 and udev 182.
I have TMPFS, DEVTMPFS, DEVTMPFS_MOUNT and SHMEN all yes.

However after the machine boots there is no /dev/shm or /dev/pts in the 
/dev/ directory and udev does not create them even though they are in 
the /usr/libexec/udev/devices directory.

Any suggestions?

Fred

--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

udev: USB HID PM screws up logitech receiver

Manuel Lauss — 2012-04-13T06:03:43

Hello,

I have a Logitech Bluetooth dongle, used in HID mode, which gets unusable on
recent kernels (3.4-rcX: the 'removable' attribute was added) due to autosuspend
being enabled on its internal hub ports (the last of rule 42-usb-hid-pm.rules),
see also a thread on linux-usb here:
http://marc.info/?l=linux-usb&m=133380762425041&w=2

Please exclude this receiver from autosuspend, as it makes it unusable.

Thanks,
        Manuel Lauss


Bus 004 Device 002: ID 046d:0b02 Logitech, Inc. BT Mini-Receiver (HID
proxy mode)
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 003: ID 046d:c70b Logitech, Inc. BT Mini-Receiver (HID
proxy mode)
Bus 004 Device 004: ID 046d:c70c Logitech, Inc. BT Mini-Receiver (HID
proxy mode)


/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ohci_hcd/5p, 12M
    |__ Port 2: Dev 2, If 0, Class=hub, Driver=hub/3p, 12M
        |__ Port 2: Dev 3, If 0, Class=HID, Driver=usbhid, 12M
        |__ Port 3: Dev 4, If 0, Class=HID, Driver=usbhid, 12M


Bus 004 Device 002:

Inconsistences using GUdev.Client

Javier Hernández Antúnez — 2012-04-12T12:59:40

Hi!

I've been porting a python application which uses gudev to use the new
gobject-introspection based bindings, but I encountered an issue. So,
I pulled udev from master and the issue was still there, so I went to
talk with some pygobject developers, and here's a retail of the
conversation.

16:12 < jhernandez> I'm using GUdev with pygobject
16:12 < jhernandez> and, I have some doubts regarding the way I'm using it
16:13 < jhernandez> with the old python-gudev, I was used to do like
this: client = gudev.Client(subsystems)
16:14 < jhernandez> using the gobject introspected bindings, I'm not
able to get my client object like I was used
16:14 < jhernandez> instead, I need to use the gudev.Client.new method
16:16 < jhernandez> should I report this as a bug? or it is my fault?
16:59 < tomeu> all GObjects should be instantiable with g_object_new
16:59 < tomeu> the problem is people doing things in _new_* that
should be done instead in _init or _construct
16:59 < tomeu> jhernandez: it's a bug that should be repor

Inconsistences using GUdev.Client

Javier Hernández Antúnez — 2012-04-12T12:18:41

Hi!

I've been porting a python application which uses gudev to use the new
gobject-introspection based bindings, but I encountered an issue. So,
I pulled udev from master and the issue was still there, so I went to
talk with some pygobject developers, and here's a retail of the
conversation.

16:12 < jhernandez> I'm using GUdev with pygobject
16:12 < jhernandez> and, I have some doubts regarding the way I'm using it
16:13 < jhernandez> with the old python-gudev, I was used to do like
this: client = gudev.Client(subsystems)
16:14 < jhernandez> using the gobject introspected bindings, I'm not
able to get my client object like I was used
16:14 < jhernandez> instead, I need to use the gudev.Client.new method
16:16 < jhernandez> should I report this as a bug? or it is my fault?
16:59 < tomeu> all GObjects should be instantiable with g_object_new
16:59 < tomeu> the problem is people doing things in _new_* that
should be done instead in _init or _construct
16:59 < tomeu> jhernandez: it's a bug that should be repor

building stand-alone udev

William Hubbs — 2012-04-04T14:19:44

Hi all,

now that the udev and systemd source trees have been merged, how do we
build udev for non-systemd setups?

Thanks much,

William

[PATCH] keymap: Add support for Lenovo v480 touchpad toggle hotkey.

Ayan George — 2012-04-03T19:19:09

---
 src/keymap/95-keymap.rules |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/src/keymap/95-keymap.rules b/src/keymap/95-keymap.rules
index 524e506..ee5b5c1 100644
--- a/src/keymap/95-keymap.rules
+++ b/src/keymap/95-keymap.rules
< at >< at > -83,6 +83,7 < at >< at > ENV{DMI_VENDOR}=="LENOVO*", ATTR{[dmi/id]product_version}=="ThinkPad X2[02]* Tab
 ENV{DMI_VENDOR}=="LENOVO*", ATTR{[dmi/id]product_version}=="*IdeaPad*", RUN+="keymap $name lenovo-ideapad"
 ENV{DMI_VENDOR}=="LENOVO*", ATTR{[dmi/id]product_name}=="S10-*", RUN+="keymap $name lenovo-ideapad"
 ENV{DMI_VENDOR}=="LENOVO", ATTR{[dmi/id]product_version}=="*IdeaPad Y550*", RUN+="keymap $name 0x95 media 0xA3 play"
+ENV{DMI_VENDOR}=="LENOVO", ATTR{[dmi/id]product_version}=="*Lenovo V480*", RUN+="keymap $name 0xf1 f21"
 
 ENV{DMI_VENDOR}=="Hewlett-Packard*", RUN+="keymap $name hewlett-packard"
 ENV{DMI_VENDOR}=="Hewlett-Packard*", ATTR{[dmi/id]product_name}=="*[tT][aA][bB][lL][eE][tT]*", RUN+="keymap $name hewlett-packard-tablet"

The future of the udev source tree

Kay Sievers — 2012-04-03T16:15:13

We are about to merge the udev sources into the systemd source tree.
After that, the next version of systemd will continue with udev’s
version numbering, i.e. jump immediately from 45 to 184.

After udev is merged into the systemd tree you can still build it for
usage outside of systemd systems, and we will support these builds
officially. In fact, we will be supporting this for a long time since
it is a necessity to make initrds (which lack systemd) work properly.
Distributions not wishing to adopt systemd can build udev pretty much
the same way as before, however should then use the systemd tarball
instead of the udev tarball and package only what is necessary of the
resulting build.

Today, ‘Init’ needs to be fully hotplug-capable; udev device
management and knowledge about device lifecycles is an integral part
of systemd and not an isolated logic. Due to this, and to minimize our
administrative workload, as well as to minimize duplication of code,
and to resolve cyclic build dependencies in the cor

[PATCH] path_id: Re-introduce SAS phy enumeration of devices v2

Nils Carlson — 2012-04-03T08:04:22

Changes since v1:
* Remove the number of phys from the output
* Extract the phy identifier from the symlink, less code.

When path_id was converted to C code the enumeration of SAS
devices by phy disappeared. This patch reintroduces enumeration
of the form

pci-0000:05:00.0-sas-phy0-0x500000e114de2b42:0-lun0

where phy0 is the reintroduced substring where 0 corresponds
to the lowest phy identifier on the port to which the device
is connected.

Please test this patch thoroughly as it has only been tested
with an older version of udev.

Signed-off-by: Nils Carlson <nils.carlson< at >ericsson.com>
---
 src/udev-builtin-path_id.c |   30 +++++++++++++++++++++++++++++-
 1 file changed, 29 insertions(+), 1 deletion(-)

diff --git a/src/udev-builtin-path_id.c b/src/udev-builtin-path_id.c
index a8559d2..54b22c4 100644
--- a/src/udev-builtin-path_id.c
+++ b/src/udev-builtin-path_id.c
< at >< at > -127,7 +127,10 < at >< at > static struct udev_device *handle_scsi_sas(struct udev_device *parent, char **pa
         struct udev_device *targetdev;

[PATCH] path_id: Re-introduce SAS phy enumeration of devices

Nils Carlson — 2012-04-02T12:56:54

When path_id was converted to C code the enumeration of SAS
devices by phy disappeared. This patch reintroduces enumeration
of the form

pci-0000:05:00.0-sas-phy0:1-0x500000e114de2b42:0-lun0

where phy0:1 is the reintroduced substring where 0 corresponds
to the lowest phy identifier on the port to which the device
is connected and 1 is the number of phys on the port.

Please test this patch thoroughly as it has only been tested
with an older version of udev.

Signed-off-by: Nils Carlson <nils.carlson< at >ericsson.com>
---
 src/udev-builtin-path_id.c |   80 +++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 79 insertions(+), 1 deletion(-)

diff --git a/src/udev-builtin-path_id.c b/src/udev-builtin-path_id.c
index a8559d2..c575fd4 100644
--- a/src/udev-builtin-path_id.c
+++ b/src/udev-builtin-path_id.c
< at >< at > -121,13 +121,67 < at >< at > out:
         return parent;
 }
 
+static int get_sas_port_phy_id(struct udev *udev, const char *phy_name)
+{
+        struct udev_device *phydev;
+        const char *phy_id_str;
+

Problems with keymap genius-slimstar-320

Robert Milasan — 2012-03-30T12:51:37

There seems to be a problem with the new keymap genius-slimstar-320
from udev 181 because it interferes with some model of KYE Systems
keyboard (actually some multimedia keys don't work because of genius
keymap in X).

If genius-slimstar-320 is removed all keys on KYE type of keyboard
works in X.

Bus 001 Device 005: ID 0458:0708 KYE Systems Corp. (Mouse Systems)
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Missing SAS phy enumeration in newer versions of udev path_id

Nils Carlson — 2012-03-30T07:59:45

Hi,

We recently upgraded our version of udev and I saw that the symlinks 
under /dev/disk/by-path/ have changed since udev started using the 
path_id C code to no longer include phy enumeration for SAS disks. Was 
this change intentional? Would anyone mind if i re-create the behavior 
of the old bash script as we were using it?

Best Regards,
Nils Carlson

--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html