http://blog.gmane.org/gmane.linux.hotplug.devel hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.linux.hotplug.devel/17439 <pre>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 &lt; at &gt;&lt; at &gt; -46,4 +46,10 &lt; at &gt;&lt; at &gt; 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 </pre> Matthew Garrett 2012-05-25T14:27:25 http://comments.gmane.org/gmane.linux.hotplug.devel/17438 <pre>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 &lt; at &gt;&lt; at &gt; -46,4 +46,10 &lt; at &gt;&lt; at &gt; 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 </pre> Matthew Garrett 2012-05-25T12:01:58 http://comments.gmane.org/gmane.linux.hotplug.devel/17437 <pre>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&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> Bruce Dubbs 2012-05-24T19:36:36 http://comments.gmane.org/gmane.linux.hotplug.devel/17435 <pre>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&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> Michal Filka 2012-05-22T13:07:14 http://comments.gmane.org/gmane.linux.hotplug.devel/17433 <pre>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&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> Michal Filka 2012-05-22T10:08:58 http://comments.gmane.org/gmane.linux.hotplug.devel/17432 <pre>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&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> John Frankish 2012-05-21T05:48:01 http://comments.gmane.org/gmane.linux.hotplug.devel/17428 <pre>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&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> F. Heitkamp 2012-05-03T12:22:47 http://comments.gmane.org/gmane.linux.hotplug.devel/17427 <pre>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&amp;id=167&amp;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 &lt;steve&lt; at &gt;digidescorp.com&gt; --- 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 &lt; at &gt;&lt; at &gt; -2,6 +2,7 &lt; at &gt;&lt; at &gt; * Copyright (c) 2001 Stephen Williams (steve&lt; at &gt;icarus.com) * Copyright (c) 2001-2002 David Brownell (dbrownell&lt; at &gt;users.sourceforge.net) * Copyright (c) 2008 Roger Williams (rawqux&lt; at &gt;users.sourceforge.net) + * Copyright (c) 2012 Steve Magnani (steve&lt; at &gt;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 &lt; at &gt;&lt; at &gt; -22,10 +23,13 &lt; at &gt;&lt; at &gt; # include &lt;stdio.h&gt; # include &lt;errno.h&gt; +# include &lt;fcntl.h&gt; # include &lt;assert.h&gt; # include &lt;limits.h&gt; +# include &lt;stdint.h&gt; # include &lt;stdlib.h&gt; # include &lt;string.h&gt; +# include &lt;unistd.h&gt; # include &lt;sys/ioctl.h&gt; &lt; at &gt;&lt; at &gt; -33,6 +37,11 &lt; at &gt;&lt; at &gt; # include &lt;linux/usb/ch9.h&gt; # include &lt;linux/usbdevice_fs.h&gt; +#ifndef _BSD_SOURCE +#define _BSD_SOURCE +#endif +#include &lt;endian.h&gt; + # include "ezusb.h" extern void logerror(const char *format, ...) &lt; at &gt;&lt; at &gt; -63,7 +72,7 &lt; at &gt;&lt; at &gt; int verbose; * return true iff [addr,addr+len) includes external RAM * for Anchorchips EZ-USB or Cypress EZ-USB FX */ -static int fx_is_external (unsigned short addr, size_t len) +static int fx_is_external (unsigned int addr, size_t len) { /* with 8KB RAM, 0x0000-0x1b3f can be written * we can't tell if it's a 4KB device here &lt; at &gt;&lt; at &gt; -82,7 +91,7 &lt; at &gt;&lt; at &gt; static int fx_is_external (unsigned shor * return true iff [addr,addr+len) includes external RAM * for Cypress EZ-USB FX2 */ -static int fx2_is_external (unsigned short addr, size_t len) +static int fx2_is_external (unsigned int addr, size_t len) { /* 1st 8KB for data/code, 0x0000-0x1fff */ if (addr &lt;= 0x1fff) &lt; at &gt;&lt; at &gt; -101,7 +110,7 &lt; at &gt;&lt; at &gt; static int fx2_is_external (unsigned sho * return true iff [addr,addr+len) includes external RAM * for Cypress EZ-USB FX2LP */ -static int fx2lp_is_external (unsigned short addr, size_t len) +static int fx2lp_is_external (unsigned int addr, size_t len) { /* 1st 16KB for data/code, 0x0000-0x3fff */ if (addr &lt;= 0x3fff) &lt; at &gt;&lt; at &gt; -117,6 +126,25 &lt; at &gt;&lt; at &gt; static int fx2lp_is_external (unsigned s } /*****************************************************************************/ +/* + * Read num_bytes from fd into buf. + * Report any errors. + */ +int read_fd(int fd, void *buf, size_t num_bytes) +{ + ssize_t bytes_read = read(fd, buf, num_bytes); + + if (bytes_read != num_bytes) { +if (bytes_read &lt; 0) + logerror("Error reading file: %s\n", strerror(errno)); +else + logerror("Truncated file\n"); + } + + return (bytes_read == num_bytes); +} + +/*****************************************************************************/ #if LINUX_VERSION_CODE &lt; KERNEL_VERSION(2,5,3) /* &lt; at &gt;&lt; at &gt; -214,17 +242,17 &lt; at &gt;&lt; at &gt; static int ezusb_write ( intdevice, char*label, unsigned charopcode, - unsigned shortaddr, + unsigned intaddr, const unsigned char*data, size_tlen ) { intstatus; if (verbose) -logerror("%s, addr 0x%04x len %4zd (0x%04zx)\n", label, addr, len, len); +logerror("%s, addr 0x%05x len %4zd (0x%04zx)\n", label, addr, len, len); status = ctrl_msg (device, USB_DIR_OUT | USB_TYPE_VENDOR | USB_RECIP_DEVICE, opcode, -addr, 0, +addr &amp; 0xFFFF, addr &gt;&gt; 16, (unsigned char *) data, len); if (status != len) { if (status &lt; 0) &lt; at &gt;&lt; at &gt; -296,8 +324,8 &lt; at &gt;&lt; at &gt; static inline int ezusb_get_eeprom_type int parse_ihex ( FILE*image, void*context, - int(*is_external)(unsigned short addr, size_t len), - int(*poke) (void *context, unsigned short addr, int external, + int(*is_external)(unsigned int addr, size_t len), + int(*poke) (void *context, unsigned int addr, int external, const unsigned char *data, size_t len) ) { &lt; at &gt;&lt; at &gt; -430,6 +458,90 &lt; at &gt;&lt; at &gt; int parse_ihex ( return 0; } +/* + * Parse a FX3 '.img' file and invoke the poke() function on the + * various segments to implement policies such as writing to RAM (with + * a one or two stage loader setup, depending on the firmware) or to + * EEPROM (two stages required). + * + * img_fd- the image file + * context- for use by poke() + * poke- called with each memory segment; errors indicated + * by returning negative values. + * + * Caller is responsible for halting CPU as needed, such as when + * overwriting a second stage loader. + */ +int parse_img ( + intimg_fd, + void*context, + int (*poke) (void *context, unsigned int addr, int external, + const unsigned char *data, size_t len) +) +{ + unsigned charheader[4]; + unsigned chardata[4096]; + intrc = -1; + + /* Validate the header */ + if (!read_fd(img_fd, header, sizeof(header))) +return -1; + + if ((header[0] != 'C') || (header[1] != 'Y')) { +logerror("Invalid file: missing CYpress signature\n"); +return -1; + } + + if (header[3] != 0xB0) { +logerror("Invalid file: format 0x%02X, expected 0xB0\n", header[3]); +return -1; + } + + /* Now process data segments */ + do { +uint32_t segment_addr, cur_addr; +uint32_t segment_len, bytes_remaining, bytes_this_chunk; + +rc = -1;/* In case of error */ +if (!read_fd(img_fd, &amp;segment_len, sizeof(segment_len))) + break; + +if (!read_fd(img_fd, &amp;segment_addr, sizeof(segment_addr))) + break; + +segment_len = le32toh(segment_len) &lt;&lt; 2; +segment_addr = le32toh(segment_addr); + +cur_addr = segment_addr; +bytes_remaining = segment_len; + +/* Make sure we poke() if segment_len == 0, + * as FX3 interprets this as a "run from address" command + */ + +do { + bytes_this_chunk = bytes_remaining; + if (bytes_this_chunk &gt; sizeof(data)) +bytes_this_chunk = sizeof(data); + + if (bytes_this_chunk &amp;&amp; !read_fd(img_fd, data, bytes_this_chunk)) { +rc = -1; +break; + } + + rc = poke (context, cur_addr, 0, data, bytes_this_chunk); + + cur_addr += bytes_this_chunk; + bytes_remaining -= bytes_this_chunk; +} while ((rc == 0) &amp;&amp; (bytes_remaining &gt; 0)); + +if (segment_len == 0) + break; + + } while (rc == 0); + + return rc; +} /*****************************************************************************/ &lt; at &gt;&lt; at &gt; -454,7 +566,7 &lt; at &gt;&lt; at &gt; struct ram_poke_context { static int ram_poke ( void*context, - unsigned shortaddr, + unsigned intaddr, intexternal, const unsigned char*data, size_tlen &lt; at &gt;&lt; at &gt; -466,7 +578,7 &lt; at &gt;&lt; at &gt; static int ram_poke ( switch (ctx-&gt;mode) { case internal_only:/* CPU should be stopped */ if (external) { - logerror("can't write %zd bytes external memory at 0x%04x\n", + logerror("can't write %zd bytes external memory at 0x%05x\n", len, addr); return -EINVAL; } &lt; at &gt;&lt; at &gt; -474,7 +586,7 &lt; at &gt;&lt; at &gt; static int ram_poke ( case skip_internal:/* CPU must be running */ if (!external) { if (verbose &gt;= 2) { -logerror("SKIP on-chip RAM, %zd bytes at 0x%04x\n", +logerror("SKIP on-chip RAM, %zd bytes at 0x%05x\n", len, addr); } return 0; &lt; at &gt;&lt; at &gt; -483,7 +595,7 &lt; at &gt;&lt; at &gt; static int ram_poke ( case skip_external:/* CPU should be stopped */ if (external) { if (verbose &gt;= 2) { -logerror("SKIP external RAM, %zd bytes at 0x%04x\n", +logerror("SKIP external RAM, %zd bytes at 0x%05x\n", len, addr); } return 0; &lt; at &gt;&lt; at &gt; -513,6 +625,51 &lt; at &gt;&lt; at &gt; static int ram_poke ( } /* + * Load a FX3 'img' file into target RAM. The dev_fd is the open "usbfs" + * device, and the path is the name of the source file. Open the file, + * parse the bytes, and write them in one or two phases. + * + * This uses the first stage loader, built into FX3 hardware but limited + * to writing on-chip memory. Everything is written during one stage. + */ +static int fx3_load_ram (int dev_fd, const char *path, int stage) +{ + intimage_fd; + struct ram_poke_contextctx; + intstatus; + + if (stage != 0) { +logerror("Two-stage load not yet supported for FX3\n"); +return -1; + } + + image_fd = open(path, O_RDONLY); + if (image_fd &lt; 0) { +logerror("%s: unable to open for input.\n", path); +return -2; + } else if (verbose) +logerror("open RAM image %s\n", path); + + ctx.device = dev_fd; + ctx.total = 0; + ctx.count = 0; + ctx.mode = internal_only; + + status = parse_img(image_fd, &amp;ctx, ram_poke); + if (status &lt; 0) { +logerror("unable to download %s\n", path); +return status; + } + + if (verbose) { +logerror("... WROTE: %d bytes, %d segments, avg %d\n", + ctx.total, ctx.count, ctx.total / ctx.count); + } + + return 0; +} + +/* * Load an Intel HEX file into target RAM. The fd is the open "usbfs" * device, and the path is the name of the source file. Open the file, * parse the bytes, and write them in one or two phases. &lt; at &gt;&lt; at &gt; -526,14 +683,19 &lt; at &gt;&lt; at &gt; static int ram_poke ( * memory is written, expecting a second stage loader to have already * been loaded. Then file is re-parsed and on-chip memory is written. */ -int ezusb_load_ram (int fd, const char *path, int fx2, int stage) +int ezusb_load_ram (int fd, const char *path, const char *type, int stage) { FILE*image; unsigned shortcpucs_addr; - int(*is_external)(unsigned short off, size_t len); + int(*is_external)(unsigned int off, size_t len); struct ram_poke_contextctx; intstatus; + /* FX3 loading differs significantly from that of previous devices */ + if (strcmp(type, "fx3") == 0) +return fx3_load_ram (fd, path, stage); + + image = fopen (path, "r"); if (image == 0) { logerror("%s: unable to open for input.\n", path); &lt; at &gt;&lt; at &gt; -542,10 +704,10 &lt; at &gt;&lt; at &gt; int ezusb_load_ram (int fd, const char * logerror("open RAM hexfile image %s\n", path); /* EZ-USB original/FX and FX2 devices differ, apart from the 8051 core */ - if (fx2 == 2) { + if (strcmp(type, "fx2lp") == 0) { cpucs_addr = 0xe600; is_external = fx2lp_is_external; - } else if (fx2) { + } else if (strcmp(type, "fx2") == 0) { cpucs_addr = 0xe600; is_external = fx2_is_external; } else { &lt; at &gt;&lt; at &gt; -622,7 +784,7 &lt; at &gt;&lt; at &gt; struct eeprom_poke_context { static int eeprom_poke ( void*context, - unsigned shortaddr, + unsigned intaddr, intexternal, const unsigned char*data, size_tlen &lt; at &gt;&lt; at &gt; -633,7 +795,7 &lt; at &gt;&lt; at &gt; static int eeprom_poke ( if (external) { logerror( - "EEPROM can't init %zd bytes external memory at 0x%04x\n", + "EEPROM can't init %zd bytes external memory at 0x%05x\n", len, addr); return -EINVAL; } &lt; at &gt;&lt; at &gt; -683,11 +845,16 &lt; at &gt;&lt; at &gt; int ezusb_load_eeprom (int dev, const ch { FILE*image; unsigned shortcpucs_addr; - int(*is_external)(unsigned short off, size_t len); + int(*is_external)(unsigned int off, size_t len); struct eeprom_poke_contextctx; intstatus; unsigned charvalue, first_byte; + if (strcmp ("fx3", type) == 0) { +logerror("FX3 EEPROM loading is not yet supported.\n"); +return -1; + } + if (ezusb_get_eeprom_type (dev, &amp;value) != 1 || value != 1) { logerror("don't see a large enough EEPROM\n"); return -1; &lt; at &gt;&lt; at &gt; -726,7 +893,7 &lt; at &gt;&lt; at &gt; int ezusb_load_eeprom (int dev, const ch is_external = fx2lp_is_external; ctx.ee_addr = 8; config &amp;= 0x4f; -fprintf (stderr, +logerror ( "FX2LP: config = 0x%02x, %sconnected, I2C = %d KHz\n", config, (config &amp; 0x40) ? "dis" : "", diff -uprN fxload-cvs/ezusb.h fxload-fx3/ezusb.h --- fxload-cvs/ezusb.h2012-04-27 12:47:44.856752994 -0500 +++ fxload-fx3/ezusb.h2012-04-27 13:54:00.930595226 -0500 &lt; at &gt;&lt; at &gt; -3,6 +3,7 &lt; at &gt;&lt; at &gt; /* * Copyright (c) 2001 Stephen Williams (steve&lt; at &gt;icarus.com) * Copyright (c) 2002 David Brownell (dbrownell&lt; at &gt;users.sourceforge.net) + * Copyright (c) 2012 Steve Magnani (steve&lt; at &gt;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 &lt; at &gt;&lt; at &gt; -24,14 +25,16 &lt; at &gt;&lt; at &gt; /* * This function loads the firmware from the given file into RAM. - * The file is assumed to be in Intel HEX format. If fx2 is set, uses - * appropriate reset commands. Stage == 0 means this is a single stage - * load (or the first of two stages). Otherwise it's the second of - * two stages; the caller preloaded the second stage loader. + * The file is assumed to be in Intel HEX format unless type is fx3. + * If type is fx2 or fx2lp, appropriate reset commands are used. + * Stage == 0 means this is a single stage load (or the first of two stages). + * Otherwise it's the second of two stages; the caller preloaded the second + * stage loader. * * The target processor is reset at the end of this download. */ -extern int ezusb_load_ram (int dev, const char *path, int fx2, int stage); +extern int ezusb_load_ram (int dev, const char *path, const char *type, +int stage); /* diff -uprN fxload-cvs/fxload.8 fxload-fx3/fxload.8 --- fxload-cvs/fxload.82012-04-27 12:47:44.856752994 -0500 +++ fxload-fx3/fxload.82012-04-27 13:37:30.059702926 -0500 &lt; at &gt;&lt; at &gt; -23,7 +23,7 &lt; at &gt;&lt; at &gt; .\" Formatted or processed versions of this manual, if unaccompanied by .\" the source, must acknowledge the copyright and authors of this work. .\" -.TH FXLOAD 8 "September 2008" "" "Linux Programmer's Manual" +.TH FXLOAD 8 "April 2012" "" "Linux Programmer's Manual" .SH "NAME" fxload \- Firmware download to EZ-USB devices .SH "SYNOPSIS" &lt; at &gt;&lt; at &gt; -31,7 +31,7 &lt; at &gt;&lt; at &gt; fxload \- Firmware download to EZ-USB de .BI "[ \-v ]" .BI "[ \-l ]" .BI "[ \-D " devpath " ]" -.BI "[ \-I " hexfile " ]" +.BI "[ \-I " firmware " ]" .BI "[ \-t " type " ]" .BI "[ \-c " config " ]" .BI "[ \-s " loader " ]" &lt; at &gt;&lt; at &gt; -47,14 +47,17 &lt; at &gt;&lt; at &gt; fxload \- Firmware download to EZ-USB de .B fxload is a program which downloads firmware to USB devices based on AnchorChips EZ-USB, Cypress EZ-USB FX, -or Cypress EZ-USB FX2/FX2LP microcontrollers. +or Cypress EZ-USB FX2/FX2LP/FX3 microcontrollers. These have 8-bit 8051 cores with special extensions for USB I/O. The FX2 supports high speed USB 2.0 transfers (480 Mbit/sec) as well as full speed USB 1.1 transfers (12 Mbit/sec), -while the earlier parts supports only full speed transfers. +while the earlier parts support only full speed transfers. +The FX3 supports super speed USB 3.0 transfers and has a 32-bit +ARM core. These controllers have several package options, and can be set up with external memory (on-chip memory is -usually 8K or 16K), EEPROMs, and ROMs when device costs allow. +usually 8K or 16K; for FX3, it is 512K), EEPROMs, and ROMs when +device costs allow. .PP This uses "usbfs" (older name: "usbdevfs") to access devices, and issues vendor specific control requests &lt; at &gt;&lt; at &gt; -87,13 +90,16 &lt; at &gt;&lt; at &gt; Note that as usual with UNIX and Linux c the order of command option flags does not matter. You may use these in any order. .TP -.BI "\-I " hexfile +.BI "\-I " firmware Downloads the specified firmware file. -This firmware is provided in standard Intel hexfile format. +For FX3 devices, the format is a Cypress-specific binary image. +For other devices, the file has standard Intel hexfile format. (Common naming conventions include .I *.hex -and -.IR *.ihx .) +, +.I *.ihx +, and +.IR *.img ). Depending on the device and firmware in use, the .B \-s option may also be necessary to specify a second stage loader. &lt; at &gt;&lt; at &gt; -146,8 +152,8 &lt; at &gt;&lt; at &gt; After downloading to a device's EEPROM, you should retest it starting from power off. .TP .BI "\-s " loader -This identifies the hex file holding a second stage loader -(in the same hex file format as the firmware itself), +This identifies the file holding a second stage loader +(in the same file format as the firmware itself), which is loaded into internal memory. This loader understands additional vendor control requests, beyond the one built into all EZ-USB hardware, &lt; at &gt;&lt; at &gt; -163,13 +169,16 &lt; at &gt;&lt; at &gt; type may be one of .I an21 (the original AnchorChips devices), .I fx -(Cypress' updated version, the EZ-USB FX), or +(Cypress' updated version, the EZ-USB FX), .I fx2 -(the Cypress EZ-USB FX2, supporting high speed transfers), or +(the Cypress EZ-USB FX2, supporting high speed transfers), .I fx2lp -(the Cypress EZ-USB FX2LP, with 16KB internal RAM). +(the Cypress EZ-USB FX2LP, with 16KB internal RAM), or +.I fx3 +(the Cypress EZ-USB FX3, supporting USB 3.0). Except when writing to EEPROM, all that normally matters when -downloading firmware is whether or not the device uses an FX2. +downloading firmware is whether or not the device uses an FX2 +or FX3. .TP .B "\-v" Prints some diagnostics, such as download addresses and sizes, &lt; at &gt;&lt; at &gt; -213,7 +222,7 &lt; at &gt;&lt; at &gt; Similarly, a second stage loader that su is needed when writing boot firmware into an I2C EEPROM. These 0xA2 and 0xA3 vendor commands are conventions defined by Cypress. Devices that use bank switching or similar mechanisms to stretch the -64KByte address space may need different approach to loading firmware. +64KByte address space may need different approaches to loading firmware. .PP Not all devices support EEPROM updates. Some EZ-USB based devices don't have an I2C EEPROM; diff -uprN fxload-cvs/main.c fxload-fx3/main.c --- fxload-cvs/main.c2012-04-27 12:47:44.856752994 -0500 +++ fxload-fx3/main.c2012-04-27 13:12:30.785424048 -0500 &lt; at &gt;&lt; at &gt; -2,6 +2,7 &lt; at &gt;&lt; at &gt; * Copyright (c) 2001 Stephen Williams (steve&lt; at &gt;icarus.com) * Copyright (c) 2001-2002 David Brownell (dbrownell&lt; at &gt;users.sourceforge.net) * Copyright (c) 2008 Roger Williams (rawqux&lt; at &gt;users.sourceforge.net) + * Copyright (c) 2012 Steve Magnani (steve&lt; at &gt;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 &lt; at &gt;&lt; at &gt; -28,7 +29,7 &lt; at &gt;&lt; at &gt; * looking for the device. * * -I &lt;path&gt; -- Download this firmware (intel hex) - * -t &lt;type&gt; -- uController type: an21, fx, fx2, fx2lp + * -t &lt;type&gt; -- uController type: an21, fx, fx2, fx2lp, fx3 * -s &lt;path&gt; -- use this second stage loader * -c &lt;byte&gt; -- Download to EEPROM, with this config byte * &lt; at &gt;&lt; at &gt; -148,6 +149,7 &lt; at &gt;&lt; at &gt; int main(int argc, char*argv[]) &amp;&amp; strcmp (optarg, "fx")// updated Cypress versions &amp;&amp; strcmp (optarg, "fx2")// Cypress USB 2.0 versions &amp;&amp; strcmp (optarg, "fx2lp")// updated FX2 + &amp;&amp; strcmp (optarg, "fx3")// Cypress USB 3.0 versions ) { logerror("illegal microcontroller type: %s\n", optarg); goto usage; &lt; at &gt;&lt; at &gt; -192,7 +194,7 &lt; at &gt;&lt; at &gt; usage: fputs ("[-s loader] [-c config_byte]\n", stderr); fputs ("\t\t[-L link] [-m mode]\n", stderr); fputs ("... [-D devpath] overrides DEVICE= in env\n", stderr); - fputs ("... device types: one of an21, fx, fx2, fx2lp\n", stderr); + fputs ("... device types: one of an21, fx, fx2, fx2lp, fx3\n", stderr); fputs ("... at least one of -I, -L, -m is required\n", stderr); return -1; } &lt; at &gt;&lt; at &gt; -200,7 +202,6 &lt; at &gt;&lt; at &gt; usage: if (ihex_path) { int fd = open(device_path, O_RDWR); int status; - intfx2; if (fd == -1) { logerror("%s : %s\n", strerror(errno), device_path); &lt; at &gt;&lt; at &gt; -209,11 +210,7 &lt; at &gt;&lt; at &gt; usage: if (type == 0) { type = "fx";/* an21-compatible for most purposes */ -fx2 = 0; - } else if (strcmp (type, "fx2lp") == 0) - fx2 = 2; - else - fx2 = (strcmp (type, "fx2") == 0); + } if (verbose) logerror("microcontroller type: %s\n", type); &lt; at &gt;&lt; at &gt; -222,7 +219,7 &lt; at &gt;&lt; at &gt; usage: /* first stage: put loader into internal memory */ if (verbose) logerror("1st stage: load 2nd stage loader\n"); -status = ezusb_load_ram (fd, stage1, fx2, 0); +status = ezusb_load_ram (fd, stage1, type, 0); if (status != 0) return status; &lt; at &gt;&lt; at &gt; -230,14 +227,14 &lt; at &gt;&lt; at &gt; usage: if (config &gt;= 0) status = ezusb_load_eeprom (fd, ihex_path, type, config); else - status = ezusb_load_ram (fd, ihex_path, fx2, 1); + status = ezusb_load_ram (fd, ihex_path, type, 1); if (status != 0) return status; } else { /* single stage, put into internal memory */ if (verbose) logerror("single stage: load on-chip memory\n"); -status = ezusb_load_ram (fd, ihex_path, fx2, 0); +status = ezusb_load_ram (fd, ihex_path, type, 0); if (status != 0) return status; } -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> Steven J. Magnani 2012-04-27T20:20:04 http://comments.gmane.org/gmane.linux.hotplug.devel/17421 <pre>(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 SUBSYSTEM=queues UDEV_LOG=3 KERNEL[537903.765683] add /devices/virtual/net/lo/queues/tx-0 (queues) ACTION=add DEVPATH=/devices/virtual/net/lo/queues/tx-0 SEQNUM=13590 SUBSYSTEM=queues UDEV_LOG=3 KERNEL[537903.844154] remove /devices/virtual/net/lo/queues/rx-0 (queues) ACTION=remove DEVPATH=/devices/virtual/net/lo/queues/rx-0 SEQNUM=13591 SUBSYSTEM=queues UDEV_LOG=3 KERNEL[537903.844192] remove /devices/virtual/net/lo/queues/tx-0 (queues) ACTION=remove DEVPATH=/devices/virtual/net/lo/queues/tx-0 SEQNUM=13592 SUBSYSTEM=queues UDEV_LOG=3 To try to track it further, I wrote a systemtap script (available at http://jim.sh/~jim/tmp/monitor.stp). It dumps the result of netlink_broadcast_filtered at lib/kobject_uevent.c:248, and then dumps the uevent_seqnum and environment at the end of the same function. It seems to show that netlink_broadcast_filter is failing to send out the event, with -ESRCH: $ sudo ./monitor.stp begin ----- netlink_broadcast_filtered: -3 (ESRCH) netlink_broadcast_filtered: -3 (ESRCH) event was: uevent_seqnum: 13588 "ACTION=add" "DEVPATH=/devices/virtual/net/lo" "SUBSYSTEM=net" "INTERFACE=lo" "IFINDEX=68" "SEQNUM=13588" ----- netlink_broadcast_filtered: 0x0 netlink_broadcast_filtered: -3 (ESRCH) event was: uevent_seqnum: 13589 "ACTION=add" "DEVPATH=/devices/virtual/net/lo/queues/rx-0" "SUBSYSTEM=queues" "SEQNUM=13589" ----- netlink_broadcast_filtered: 0x0 netlink_broadcast_filtered: -3 (ESRCH) event was: uevent_seqnum: 13590 "ACTION=add" "DEVPATH=/devices/virtual/net/lo/queues/tx-0" "SUBSYSTEM=queues" "SEQNUM=13590" ----- netlink_broadcast_filtered: 0x0 netlink_broadcast_filtered: -3 (ESRCH) event was: uevent_seqnum: 13591 "ACTION=remove" "DEVPATH=/devices/virtual/net/lo/queues/rx-0" "SUBSYSTEM=queues" "SEQNUM=13591" ----- netlink_broadcast_filtered: 0x0 netlink_broadcast_filtered: -3 (ESRCH) event was: uevent_seqnum: 13592 "ACTION=remove" "DEVPATH=/devices/virtual/net/lo/queues/tx-0" "SUBSYSTEM=queues" "SEQNUM=13592" ----- netlink_broadcast_filtered: -3 (ESRCH) netlink_broadcast_filtered: -3 (ESRCH) event was: uevent_seqnum: 13593 "ACTION=remove" "DEVPATH=/devices/virtual/net/lo" "SUBSYSTEM=net" "INTERFACE=lo" "IFINDEX=68" "SEQNUM=13593" ----- ^Cend Is it expected that those events would not be sent like that? If not, is there something else I can do to track this further? Or, if that's expected behavior, is there anything "udevadm settle" can do to avoid the timeout? -jim -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> Jim Paris 2012-04-22T04:36:55 http://comments.gmane.org/gmane.linux.hotplug.devel/17419 <pre> 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&lt; at &gt;typhoon-base-unit0:/root&gt; 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 parent device. looking at device '/block/sda': KERNEL=="sda" SUBSYSTEM=="block" DRIVER=="" ATTR{range}=="16" ATTR{ext_range}=="256" ATTR{removable}=="0" ATTR{ro}=="0" ATTR{size}=="586072368" ATTR{alignment_offset}=="0" ATTR{discard_alignment}=="0" ATTR{capability}=="50" ATTR{stat}==" 12 3 80 50 0 0 0 0 0 50 50" ATTR{inflight}==" 0 0" root&lt; at &gt;typhoon-base-unit0:/root&gt; udevadm info -p /block/sda -q all P: /block/sda N: sda S: scsi/host/bus/target/lun/disc S: discs/disc0/disc S: block/8:0 S: disk/by-id/scsi-1ATA_WDC_WD3000BLHX-01V7BV0_WD-WX61E41PY599 E: UDEV_LOG=3 E: DEVPATH=/block/sda E: SUBSYSTEM=block E: DEVNAME=sda E: ID_SCSI=1 E: ID_VENDOR=ATA E: ID_VENDOR_ENC=ATA\x20\x20\x20\x20\x20 E: ID_MODEL=WDC_WD3000BLHX-0 E: ID_MODEL_ENC=WDC\x20WD3000BLHX-0 E: ID_REVISION=04.0 E: ID_TYPE=disk E: ID_SERIAL=1ATA_WDC_WD3000BLHX-01V7BV0_WD-WX61E41PY599 E: ID_SERIAL_SHORT=ATA_WDC_WD3000BLHX-01V7BV0_WD-WX61E41PY599 E: ID_SCSI_SERIAL=WD-WX61E41PY599 E: ID_BUS=scsi E: MAJOR=8 E: MINOR=0 E: DEVTYPE=disk E: PHYSDEVPATH=/devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0 E: PHYSDEVBUS=scsi E: PHYSDEVDRIVER=sd E: DEVLINKS=/dev/scsi/host/bus/target/lun/disc /dev/discs/disc0/disc /dev/block/8:0 /dev/disk/by-id/scsi-1ATA_WDC_WD3000BLHX-01V7BV0_WD-WX61E41PY599 root&lt; at &gt;typhoon-base-unit0:/root&gt; ls -l /sys/block/sda total 0 -r--r--r-- 1 root root 4096 Apr 18 14:16 alignment_offset lrwxrwxrwx 1 root root 0 Apr 18 14:16 bdi -&gt; ../../class/bdi/8:0 -r--r--r-- 1 root root 4096 Apr 18 14:16 capability -r--r--r-- 1 root root 4096 Apr 18 14:16 dev lrwxrwxrwx 1 root root 0 Apr 18 14:16 device -&gt; ../../devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0 -r--r--r-- 1 root root 4096 Apr 18 14:16 discard_alignment -r--r--r-- 1 root root 4096 Apr 18 14:16 ext_range drwxr-xr-x 2 root root 0 Apr 18 14:16 holders -r--r--r-- 1 root root 4096 Apr 18 14:16 inflight drwxr-xr-x 2 root root 0 Apr 18 14:16 power drwxr-xr-x 3 root root 0 Apr 18 14:16 queue -r--r--r-- 1 root root 4096 Apr 18 14:16 range -r--r--r-- 1 root root 4096 Apr 18 14:16 removable -r--r--r-- 1 root root 4096 Apr 18 14:16 ro drwxr-xr-x 4 root root 0 Apr 18 14:16 sda1 drwxr-xr-x 4 root root 0 Apr 18 14:16 sda2 -r--r--r-- 1 root root 4096 Apr 18 14:16 size drwxr-xr-x 2 root root 0 Apr 18 14:16 slaves -r--r--r-- 1 root root 4096 Apr 18 14:16 stat lrwxrwxrwx 1 root root 0 Apr 18 14:16 subsystem -&gt; ../../block -rw-r--r-- 1 root root 4096 Apr 18 14:16 uevent Thanks, Chris </pre> Chris Friesen 2012-04-18T21:42:59 http://comments.gmane.org/gmane.linux.hotplug.devel/17412 <pre>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&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> F. Heitkamp 2012-04-18T12:41:29 http://comments.gmane.org/gmane.linux.hotplug.devel/17411 <pre>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&amp;m=133380762425041&amp;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: ID 046d:0b02 Logitech, Inc. BT Mini-Receiver (HID proxy mode) Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 9 Hub bDeviceSubClass 0 Unused bDeviceProtocol 0 Full speed (or root) hub bMaxPacketSize0 8 idVendor 0x046d Logitech, Inc. idProduct 0x0b02 BT Mini-Receiver (HID proxy mode) bcdDevice 40.06 iManufacturer 1 Logitech iProduct 2 Logitech BT Mini-Receiver iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 25 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 Unused bInterfaceProtocol 0 Full speed (or root) hub iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0001 1x 1 bytes bInterval 255 Hub Descriptor: bLength 9 bDescriptorType 41 nNbrPorts 3 wHubCharacteristic 0x0004 Ganged power switching Compound device Ganged overcurrent protection bPwrOn2PwrGood 50 * 2 milli seconds bHubContrCurrent 100 milli Ampere DeviceRemovable 0x0c PortPwrCtrlMask 0xff Hub Port Status: Port 1: 0000.0100 power Port 2: 0000.0103 power enable connect Port 3: 0000.0103 power enable connect Device Status: 0x0000 (Bus Powered) Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 9 Hub bDeviceSubClass 0 Unused bDeviceProtocol 0 Full speed (or root) hub bMaxPacketSize0 64 idVendor 0x1d6b Linux Foundation idProduct 0x0001 1.1 root hub bcdDevice 3.04 iManufacturer 3 Linux 3.4.0-rc2-00270-g00413fe ohci_hcd iProduct 2 OHCI Host Controller iSerial 1 0000:00:12.0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 25 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 Unused bInterfaceProtocol 0 Full speed (or root) hub iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0002 1x 2 bytes bInterval 255 Hub Descriptor: bLength 9 bDescriptorType 41 nNbrPorts 5 wHubCharacteristic 0x0002 No power switching (usb 1.0) Ganged overcurrent protection bPwrOn2PwrGood 2 * 2 milli seconds bHubContrCurrent 0 milli Ampere DeviceRemovable 0x00 PortPwrCtrlMask 0xff Hub Port Status: Port 1: 0000.0100 power Port 2: 0000.0103 power enable connect Port 3: 0000.0100 power Port 4: 0000.0100 power Port 5: 0000.0100 power Device Status: 0x0001 Self Powered Bus 004 Device 003: ID 046d:c70b Logitech, Inc. BT Mini-Receiver (HID proxy mode) Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x046d Logitech, Inc. idProduct 0xc70b BT Mini-Receiver (HID proxy mode) bcdDevice 40.06 iManufacturer 1 Logitech iProduct 2 Logitech BT Mini-Receiver iSerial 3 00076146494E bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 34 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 4 RR40.06_B0077 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 98mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 1 Boot Interface Subclass bInterfaceProtocol 1 Keyboard iInterface 0 HID Device Descriptor: bLength 9 bDescriptorType 33 bcdHID 1.11 bCountryCode 0 Not supported bNumDescriptors 1 bDescriptorType 34 Report wDescriptorLength 59 Report Descriptors: ** UNAVAILABLE ** Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 10 Device Status: 0x0000 (Bus Powered) Bus 004 Device 004: ID 046d:c70c Logitech, Inc. BT Mini-Receiver (HID proxy mode) Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x046d Logitech, Inc. idProduct 0xc70c BT Mini-Receiver (HID proxy mode) bcdDevice 40.06 iManufacturer 1 Logitech iProduct 2 Logitech BT Mini-Receiver iSerial 3 00076146494E bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 34 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 4 RR40.06_B0077 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 98mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 1 Boot Interface Subclass bInterfaceProtocol 2 Mouse iInterface 0 HID Device Descriptor: bLength 9 bDescriptorType 33 bcdHID 1.11 bCountryCode 0 Not supported bNumDescriptors 1 bDescriptorType 34 Report wDescriptorLength 226 Report Descriptors: ** UNAVAILABLE ** Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 5 Device Status: 0x0000 (Bus Powered) -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> Manuel Lauss 2012-04-13T06:03:43 http://comments.gmane.org/gmane.linux.hotplug.devel/17409 <pre>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 &lt; jhernandez&gt; I'm using GUdev with pygobject 16:12 &lt; jhernandez&gt; and, I have some doubts regarding the way I'm using it 16:13 &lt; jhernandez&gt; with the old python-gudev, I was used to do like this: client = gudev.Client(subsystems) 16:14 &lt; jhernandez&gt; using the gobject introspected bindings, I'm not able to get my client object like I was used 16:14 &lt; jhernandez&gt; instead, I need to use the gudev.Client.new method 16:16 &lt; jhernandez&gt; should I report this as a bug? or it is my fault? 16:59 &lt; tomeu&gt; all GObjects should be instantiable with g_object_new 16:59 &lt; tomeu&gt; the problem is people doing things in _new_* that should be done instead in _init or _construct 16:59 &lt; tomeu&gt; jhernandez: it's a bug that should be reported 17:00 &lt; tomeu&gt; (in GUDev) 17:00 &lt; jhernandez&gt; tomeu: ACK JFYI, the full conversation log is here [1] I think the final decision on this is up to udev/gudev developers, and I'll try (with some help) to provide a patch if it is really needed. My devel environment consists in: - openSUSE 12.1 + Official updates - udev pulled from master (182) Best regards! [1]: http://pastebin.com/js7rKh3J </pre> Javier Hernández Antúnez 2012-04-12T12:59:40 http://comments.gmane.org/gmane.linux.hotplug.devel/17408 <pre>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 &lt; jhernandez&gt; I'm using GUdev with pygobject 16:12 &lt; jhernandez&gt; and, I have some doubts regarding the way I'm using it 16:13 &lt; jhernandez&gt; with the old python-gudev, I was used to do like this: client = gudev.Client(subsystems) 16:14 &lt; jhernandez&gt; using the gobject introspected bindings, I'm not able to get my client object like I was used 16:14 &lt; jhernandez&gt; instead, I need to use the gudev.Client.new method 16:16 &lt; jhernandez&gt; should I report this as a bug? or it is my fault? 16:59 &lt; tomeu&gt; all GObjects should be instantiable with g_object_new 16:59 &lt; tomeu&gt; the problem is people doing things in _new_* that should be done instead in _init or _construct 16:59 &lt; tomeu&gt; jhernandez: it's a bug that should be reported 17:00 &lt; tomeu&gt; (in GUDev) 17:00 &lt; jhernandez&gt; tomeu: ACK JFYI, the full conversation log is here [1] I think the final decision on this is up to udev/gudev developers, and I'll try (with some help) to provide a patch if it is really needed. My devel environment consists in: - openSUSE 12.1 + Official updates - udev pulled from master (182) Best regards! [1]: http://pastebin.com/js7rKh3J </pre> Javier Hernández Antúnez 2012-04-12T12:18:41 http://comments.gmane.org/gmane.linux.hotplug.devel/17401 <pre>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 </pre> William Hubbs 2012-04-04T14:19:44 http://comments.gmane.org/gmane.linux.hotplug.devel/17397 <pre>--- 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 &lt; at &gt;&lt; at &gt; -83,6 +83,7 &lt; at &gt;&lt; at &gt; 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" </pre> Ayan George 2012-04-03T19:19:09 http://comments.gmane.org/gmane.linux.hotplug.devel/17392 <pre>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 core OS, we have decided to merge the two projects. The udev built from the systemd source tree will stay compatible with non-systemd init systems for a long time. This change is mostly a detail of the build scheme, rather than a change of direction or interfaces. Accordingly, the libudev API is untouched by these build infrastructure changes. For us, compatibility is key. -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> Kay Sievers 2012-04-03T16:15:13 http://comments.gmane.org/gmane.linux.hotplug.devel/17391 <pre>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 &lt;nils.carlson&lt; at &gt;ericsson.com&gt; --- 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 &lt; at &gt;&lt; at &gt; -127,7 +127,10 &lt; at &gt;&lt; at &gt; static struct udev_device *handle_scsi_sas(struct udev_device *parent, char **pa struct udev_device *targetdev; struct udev_device *target_parent; struct udev_device *sasdev; +struct udev_device *portdev; +struct udev_list_entry *list_entry; const char *sas_address; +int tmp_phy_id, phy_id = 255; char *lun = NULL; targetdev = udev_device_get_parent_with_subsystem_devtype(parent, "scsi", "scsi_target"); &lt; at &gt;&lt; at &gt; -138,6 +141,31 &lt; at &gt;&lt; at &gt; static struct udev_device *handle_scsi_sas(struct udev_device *parent, char **pa if (target_parent == NULL) return NULL; +portdev = udev_device_get_parent(target_parent); +if (target_parent == NULL) +return NULL; + +udev_list_entry_foreach(list_entry, +udev_device_get_sysattr_list_entry(portdev)) { +const char *name = udev_list_entry_get_name(list_entry); +char *phy_id_str; + +if (strncmp(name, "phy", 3) != 0) +continue; + +phy_id_str = strstr(name, ":"); +if (phy_id_str == NULL) +continue; + +phy_id_str++; + +tmp_phy_id = atoi(phy_id_str); +if (tmp_phy_id &gt;= 0 &amp;&amp; tmp_phy_id &lt; phy_id) +phy_id = tmp_phy_id; +} +if (phy_id == 255) +return NULL; + sasdev = udev_device_new_from_subsystem_sysname(udev, "sas_device", udev_device_get_sysname(target_parent)); if (sasdev == NULL) &lt; at &gt;&lt; at &gt; -150,7 +178,7 &lt; at &gt;&lt; at &gt; static struct udev_device *handle_scsi_sas(struct udev_device *parent, char **pa } format_lun_number(parent, &amp;lun); - path_prepend(path, "sas-%s-%s", sas_address, lun); +path_prepend(path, "sas-phy%d-%s-%s", phy_id, sas_address, lun); if (lun) free(lun); out: </pre> Nils Carlson 2012-04-03T08:04:22 http://comments.gmane.org/gmane.linux.hotplug.devel/17386 <pre>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 &lt;nils.carlson&lt; at &gt;ericsson.com&gt; --- 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 &lt; at &gt;&lt; at &gt; -121,13 +121,67 &lt; at &gt;&lt; at &gt; 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; + int phy_id = -1; + + phydev = udev_device_new_from_subsystem_sysname(udev, "sas_phy", + phy_name); + if (phydev == NULL) { + return -1; + } + + phy_id_str = udev_device_get_sysattr_value(phydev, "phy_identifier"); + if (phy_id_str == NULL) { + goto out; + } + + phy_id = atoi(phy_id_str); + +out: + udev_device_unref(phydev); + + return phy_id; +} + +static int get_sas_port_num_phys(struct udev *udev, const char *port_name) +{ + struct udev_device *portdev; + const char *num_phys_str; + int num_phys = -1; + + portdev = udev_device_new_from_subsystem_sysname(udev, "sas_port", + port_name); + if (portdev == NULL) { + return -1; + } + + num_phys_str = udev_device_get_sysattr_value(portdev, "num_phys"); + if (num_phys_str == NULL) { + goto out; + } + + num_phys = atoi(num_phys_str); + +out: + udev_device_unref(portdev); + + return num_phys; +} + static struct udev_device *handle_scsi_sas(struct udev_device *parent, char **path) { struct udev *udev = udev_device_get_udev(parent); struct udev_device *targetdev; struct udev_device *target_parent; struct udev_device *sasdev; +struct udev_device *portdev; +struct udev_list_entry *list_entry; const char *sas_address; +int tmp_phy_id, phy_id = 255; +int num_phys; char *lun = NULL; targetdev = udev_device_get_parent_with_subsystem_devtype(parent, "scsi", "scsi_target"); &lt; at &gt;&lt; at &gt; -138,6 +192,29 &lt; at &gt;&lt; at &gt; static struct udev_device *handle_scsi_sas(struct udev_device *parent, char **pa if (target_parent == NULL) return NULL; +portdev = udev_device_get_parent(target_parent); +if (target_parent == NULL) +return NULL; + +udev_list_entry_foreach(list_entry, +udev_device_get_sysattr_list_entry(portdev)) { +const char *name = udev_list_entry_get_name(list_entry); + +if (strncmp(name, "phy", 3) != 0) +continue; + +tmp_phy_id = get_sas_port_phy_id(udev, name); +if (tmp_phy_id &gt;= 0 &amp;&amp; tmp_phy_id &lt; phy_id) +phy_id = tmp_phy_id; +} +if (phy_id == 255) +return NULL; + +num_phys = get_sas_port_num_phys(udev, + udev_device_get_sysname(portdev)); +if (num_phys &lt; 0) +return NULL; + sasdev = udev_device_new_from_subsystem_sysname(udev, "sas_device", udev_device_get_sysname(target_parent)); if (sasdev == NULL) &lt; at &gt;&lt; at &gt; -150,7 +227,8 &lt; at &gt;&lt; at &gt; static struct udev_device *handle_scsi_sas(struct udev_device *parent, char **pa } format_lun_number(parent, &amp;lun); - path_prepend(path, "sas-%s-%s", sas_address, lun); +path_prepend(path, "sas-phy%d:%d-%s-%s", phy_id, num_phys, + sas_address, lun); if (lun) free(lun); out: </pre> Nils Carlson 2012-04-02T12:56:54 http://comments.gmane.org/gmane.linux.hotplug.devel/17385 <pre>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&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> Robert Milasan 2012-03-30T12:51:37 http://comments.gmane.org/gmane.linux.hotplug.devel/17383 <pre>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&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> Nils Carlson 2012-03-30T07:59:45 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.linux.hotplug.devel