gmane.linux.hotplug.devel

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

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

Re: bus id match

Hannes Reinecke — 2012-05-22T13:09:10

You can't rename network interfaces in state 'UP'.
That only works for unconfigured interfaces.

Cheers,

Hannes

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/majordomo-info.html

Re: udev, net device alias

Hannes Reinecke — 2012-05-22T10:14:21

Here holds the Highlander-Mantra:

There can only be one.

Network devices do not have symlinks, but rather live in the kernel
namespace. And the name is the primary key for finding this device.
To have network device aliases you would need to implement an
additional infrastructure within the kernel.

And get that past Dave Miller :-)

Cheers,

Hannes

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

Re: Inconsistences using GUdev.Client

Martin Pitt — 2012-05-06T12:55:53

Hello again,

Martin Pitt [2012-05-05 14:42 -0700]:

For the record, all done now:

http://git.gnome.org/browse/pygobject/commit/?id=f2494526e1c
http://git.gnome.org/browse/pygobject/commit/?id=8321af2c7df
http://git.gnome.org/browse/pygobject/commit/?id=9f50fd214e4

However, setting GStrv properties in the constructor has already
worked before.

Martin

Re: Inconsistences using GUdev.Client

Martin Pitt — 2012-05-05T21:42:02

David Zeuthen [2012-04-12 11:32 -0400]:

Is that still the case? I just tried this with current PyGObject
3.2.0, and it seems to work:

$ python
['usb']

I also tested with "GUdev.Client(subsystems=['usb'])", i. e. using the
GObject constructor instead of gudev_client_new(), and it works just
as well.

I am just committing test cases for handling GStrv properties to g-i
and pygobject, and indeed a few cases don't work yet (such as defining
GStrv properties in Python, and _setting_ GStrv properties). I'm
working my way through fixing those.

Thanks,

Martin

Re: modprobe.d question.

Kay Sievers — 2012-05-03T14:58:37

Poor choice. :)


Right, that's the generic SYSV style, and should work.


No, that makes no sense. modprobe config is only read if modprobe is
called, but nothing will call it. And 'install' instructions are a
very broken concept, and should not be used. Besides the fact that the
above would not work anyway, because it would never be triggered.


That should work fine on Debian, just add it there.


That does not matter.


It needs to support /etc/modules, which is a Debian-specific file.

Kay
--
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://vger.kernel.org/majordomo-info.html

[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  <stdio.h>
 # include  <errno.h>
+# include  <fcntl.h>
 # include  <assert.h>
 # include  <limits.h>
+# include  <stdint.h>
 # include  <stdlib.h>
 # include  <string.h>
+# include  <unistd.h>
 
 # include  <sys/ioctl.h>
 
< at >< at > -33,6 +37,11 < at >< at >
 # include  <linux/usb/ch9.h>
 # include  <linux/usbdevice_fs.h>
 
+#ifndef _BSD_SOURCE
+#define _BSD_SOURCE
+#endif
+#include <endian.h>
+
 # include "ezusb.h"
 
 extern void logerror(const char *format, ...)
< at >< at > -63,7 +72,7 < at >< at > 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
< at >< at > -82,7 +91,7 < at >< at > 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 <= 0x1fff)
< at >< at > -101,7 +110,7 < at >< at > 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 <= 0x3fff)
< at >< at > -117,6 +126,25 < at >< at > 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 < 0)
+    logerror("Error reading file: %s\n", strerror(errno));
+else
+    logerror("Truncated file\n");
+    }
+
+    return (bytes_read == num_bytes);
+}
+
+/*****************************************************************************/
 
 #if LINUX_VERSION_CODE < KERNEL_VERSION(2,5,3)
 /*
< at >< at > -214,17 +242,17 < at >< at > 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 & 0xFFFF, addr >> 16,
 (unsigned char *) data, len);
     if (status != len) {
 if (status < 0)
< at >< at > -296,8 +324,8 < at >< at > 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)
 )
 {
< at >< at > -430,6 +458,90 < at >< at > 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, &segment_len, sizeof(segment_len)))
+    break;
+
+if (!read_fd(img_fd, &segment_addr, sizeof(segment_addr)))
+    break;
+
+segment_len  = le32toh(segment_len) << 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 > sizeof(data))
+bytes_this_chunk = sizeof(data);
+
+    if (bytes_this_chunk && !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) && (bytes_remaining > 0));
+
+if (segment_len == 0)
+    break;
+
+    } while (rc == 0);
+
+    return rc;
+}
 
 /*****************************************************************************/
 
< at >< at > -454,7 +566,7 < at >< at > struct ram_poke_context {
 
 static int ram_poke (
     void*context,
-    unsigned shortaddr,
+    unsigned intaddr,
     intexternal,
     const unsigned char*data,
     size_tlen
< at >< at > -466,7 +578,7 < at >< at > static int ram_poke (
     switch (ctx->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;
 }
< at >< at > -474,7 +586,7 < at >< at > static int ram_poke (
     case skip_internal:/* CPU must be running */
 if (!external) {
     if (verbose >= 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;
< at >< at > -483,7 +595,7 < at >< at > static int ram_poke (
     case skip_external:/* CPU should be stopped */
 if (external) {
     if (verbose >= 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;
< at >< at > -513,6 +625,51 < at >< at > 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 < 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, &ctx, ram_poke);
+    if (status < 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.
< at >< at > -526,14 +683,19 < at >< at > 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);
< at >< at > -542,10 +704,10 < at >< at > 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 {
< at >< at > -622,7 +784,7 < at >< at > struct eeprom_poke_context {
 
 static int eeprom_poke (
     void*context,
-    unsigned shortaddr,
+    unsigned intaddr,
     intexternal,
     const unsigned char*data,
     size_tlen
< at >< at > -633,7 +795,7 < at >< at > 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;
     }
< at >< at > -683,11 +845,16 < at >< at > 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, &value) != 1 || value != 1) {
 logerror("don't see a large enough EEPROM\n");
 return -1;
< at >< at > -726,7 +893,7 < at >< at > int ezusb_load_eeprom (int dev, const ch
 is_external = fx2lp_is_external;
 ctx.ee_addr = 8;
 config &= 0x4f;
-fprintf (stderr,
+logerror (
     "FX2LP:  config = 0x%02x, %sconnected, I2C = %d KHz\n",
     config,
     (config & 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
< at >< at > -3,6 +3,7 < at >< at >
 /*
  * Copyright (c) 2001 Stephen Williams (steve< at >icarus.com)
  * Copyright (c) 2002 David Brownell (dbrownell< 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 > -24,14 +25,16 < at >< at >
 
 /*
  * 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
< at >< at > -23,7 +23,7 < at >< at >
 .\" 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"
< at >< at > -31,7 +31,7 < at >< at > 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 " ]"
< at >< at > -47,14 +47,17 < at >< at > 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
< at >< at > -87,13 +90,16 < at >< at > 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.
< at >< at > -146,8 +152,8 < at >< at > 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,
< at >< at > -163,13 +169,16 < at >< at > 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,
< at >< at > -213,7 +222,7 < at >< at > 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
< 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 > -28,7 +29,7 < at >< at >
  * looking for the device.
  *
  *     -I <path>       -- Download this firmware (intel hex)
- *     -t <type>       -- uController type: an21, fx, fx2, fx2lp
+ *     -t <type>       -- uController type: an21, fx, fx2, fx2lp, fx3
  *     -s <path>       -- use this second stage loader
  *     -c <byte>       -- Download to EEPROM, with this config byte
  *
< at >< at > -148,6 +149,7 < at >< at > int main(int argc, char*argv[])
     && strcmp (optarg, "fx")// updated Cypress versions
     && strcmp (optarg, "fx2")// Cypress USB 2.0 versions
     && strcmp (optarg, "fx2lp")// updated FX2
+    && strcmp (optarg, "fx3")// Cypress USB 3.0 versions
     ) {
 logerror("illegal microcontroller type: %s\n", optarg);
 goto usage;
< at >< at > -192,7 +194,7 < at >< at > 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;
       }
< at >< at > -200,7 +202,6 < at >< at > 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);
< at >< at > -209,11 +210,7 < at >< at > 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);
< at >< at > -222,7 +219,7 < at >< at > 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;
 
< at >< at > -230,14 +227,14 < at >< at > usage:
 if (config >= 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< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: udev missing events?

Frank Ch. Eigler — 2012-04-27T13:59:49

Jim Paris <jim< at >jtan.com> writes:


By the way, your monitor.stp contains this bit:

   /* I don't know how to do this better, indexing envp
   if ($env->envp_idx > 0) printf("  %s\n", $env->envp[0]$)
   if ($env->envp_idx > 1) printf("  %s\n", $env->envp[1]$)
   [...]
   if ($env->envp_idx > 9) printf("  %s\n", $env->envp[9]$)
   if ($env->envp_idx > 10) printf("..... more\n")

More idiomatic would be as follows (stap version 0.9.9+):

   for (i=0; i<$env->envp_idx; i++) {
       printf("  %s\n", $env->envp[i]$)
   }

- FChE
--
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 global properties

John Sheu — 2012-04-24T08:35:36

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

Re: udev missing events?

Jim Paris — 2012-04-22T16:54:01

Yeah.


The specific problem is that virt-manager loses its connection to
libvirt.  Libvirt triggers this situation, and then later executes
"udevadm settle" after some of virt-manager's storage requests.  I
think that happens in one thread, while another libvirt thread then
kills the virt-manager connection for stalling for so long.

I can certainly ask the libvirt guys to add a shorter --timeout
parameter, at the very least, if this isn't considered a bug from the
udev point of view.  But libvirt isn't the only thing that calls
"udevadm settle" -- having to wait 2-3 minutes for each settle call
during an initramfs build or similar would also be annoying.


I upgraded libvirt and the kernel lately, so either some of this lxc
probing code in libvirt is new, or maybe my kernel didn't support net
namespaces before.  Libvirt has called udevadm settle for a while,
though.

Thanks,
-jim
--
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

Re: udev missing events?

Jim Paris — 2012-04-22T14:11:06

I'm not using them on purpose, but it's caused by a probing clone() in
libvirt's lxcContainerAavilable, followed by a "ip link set lo netns -1"
in lxcCheckNetNsSupport.  It can be recreated with just:

  #include <unistd.h>
  #include <sched.h>
  static int dummy(void *argv) { _exit(0); }
  main() {
          char stack[4096];
          clone(dummy, stack+4096, CLONE_NEWNET, NULL);
          wait();
          system("ip link set lo netns -1");
  }

Running that program causes "udevadm settle" to stop working due to
the filtered events.

-jim
--
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 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=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< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

"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 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< at >typhoon-base-unit0:/root> 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< at >typhoon-base-unit0:/root> 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 -> ../../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 -> ../../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 -> ../../block
-rw-r--r-- 1 root root 4096 Apr 18 14:16 uevent


Thanks,
Chris

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

F. Heitkamp — 2012-04-19T03:20:23

Sorry.  The devices directory is "/lib/udev/devices".

udev seems to be mostly working AFAICT.  When I plug/unplug USB or 
firewire, I can see events being processed with udevadm monitor.

There is no shm or pts directory shown in /proc/devices.  Should there be?

There is also lots of information in the /run directory tree.

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

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

Kay Sievers — 2012-04-18T22:41:03

On old kernels, the chain of parent devices was not always properly
exported, because the "struct class_device" created all device
directories and spread spread them all over the the /sys/class tree.
There was a "device" link created at these disconnected device
directories, which udev tried to follow to find the parents.

We cleaned that up that mess, by having a single and unified tree in
/sys/devices, and /sys/class and /sys/bus just have symlinks pointing
into that tree. "Hierarchy" vs. "classification" are properly
separated that way.

For a while the CONFIG_SYSFS_DEPRECATED controlled the behaviour, you
might check if that is available in your kernel and can be turned off
to switch to the unified hierarchy. I kind of lost track which kernel
versions did what here.

In general, if you need the more recent udev tools to work regarding
the chain of parents, which "udevadm info --attribute-walk" uses, you
need a newer kernel, which exports that natively. There is no support
for the "device" link in newer versions of udev. We only really
supports it the other way around, which is new kernels on older
userspace. So you either use a newer kernel for a new udev, or also
stick with the old udev if you are stuck with that old kernel.

Or alternatively, you patch-in the support for the old "struct
class_device" stuff into the curent udev, to support older kernels; it
should be fairly simple. If that's what you look for, I can look up
the stuff you need to add, just let me know.

Kay
--
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

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

Chris Friesen — 2012-04-18T22:13:08

Looking at the udevadm code led me to the following:

On the problematic 2.6.34 machine:

root< at >typhoon-base-unit0:/root> ls -l /sys/dev/block/
<snip>
lrwxrwxrwx 1 root root 0 Apr 18 14:34 8:0 -> ../../block/sda



On my 2.6.35 machine:

[cfriesen< at >blah udev-173]$ ls -l /sys/dev/block/
<snip>
lrwxrwxrwx. 1 root root 0 Apr 18 15:54 8:0 -> ../../devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda



So where do I go from here?  Is there a simple kernel change to make my 2.6.34
kernel behave more like the more recent one?  Would an older version of udev be
able to parse my 2.6.34 /sys directory properly, or do I need to figure out a
way to parse /sys manually?

Thanks,
Chris