headers
Matthew Garrett | 25 May 16:27
Picon
Favicon

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

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
@@ -46,4 +46,10 @@ 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{removable}=="fixed",
TEST=="../power/control", ATTR{../power/control}="auto"
+
+LABEL="usb_hid_pm_end"
\ No newline at end of file
--

--
(Continue reading)

Permalink | Reply | 0 comments |
headers
Matthew Garrett | 25 May 14:01
Picon
Favicon

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

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
@@ -46,4 +46,10 @@ 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{removable}=="fixed",
TEST=="../power/control", ATTR{../power/control}="auto"
+
+LABEL="usb_add_pm_end"
\ No newline at end of file
--

-- 
1.7.10.2

--
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bruce Dubbs | 24 May 21:36
Picon

systemd-183

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
Permalink | Reply | 0 comments |
headers
Michal Filka | 22 May 15:07
Picon

bus id match

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?
(Continue reading)

Permalink | Reply | 1 comment |
headers
Michal Filka | 22 May 12:08
Picon

udev, net device alias

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
Permalink | Reply | 1 comment |
headers
John Frankish | 21 May 07:48
Picon
Favicon

Missing ID_BUS, ID_TYPE

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
Permalink | Reply | 0 comments |
headers
F. Heitkamp | 3 May 14:22
Picon

modprobe.d question.

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://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 1 comment |
headers
Steven J. Magnani | 27 Apr 22:20

[PATCH] fxload: Add support for loading FX3 RAM

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.c	2012-04-27 12:47:44.856752994 -0500
+++ fxload-fx3/ezusb.c	2012-04-27 14:45:50.083897780 -0500
@@ -2,6 +2,7 @@
  * 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
@@ -22,10 +23,13 @@

 # include  <stdio.h>
 # include  <errno.h>
+# include  <fcntl.h>
 # include  <assert.h>
 # include  <limits.h>
+# include  <stdint.h>
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Sheu | 24 Apr 10:35
Picon

udev global properties

I'm noticing that udev global properties (e.g. those set with "udevadm
control --property=KEY=VALUE") aren't propagated to the udev device
database, so, for example, they don't show up when using "udevadm
info".  Is there a particular reason we do this?

Thanks,
-John Sheu
--
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
Permalink | Reply | 0 comments |
headers
Jim Paris | 22 Apr 16:11
Gravatar

Re: udev missing events?

Eric W. Biederman wrote:
> Jim Paris <jim <at> jtan.com> wrote:
> 
> >(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
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jim Paris | 22 Apr 06:36
Gravatar

udev missing events?

(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=13589
(Continue reading)

Permalink | Reply | 1 comment |

Gmane