Eagle and ADI 930 usb adsl modem driver

Hi,

attached is the driver for USB ADSL modems based on the ADI eagle chipset using the usb_atm infrastructure.

Quoted 6 lines

(quoted diff) +6 -0

+/*
+ * sometime hotplug don't have time to give the firmware the
+ * first time, retry it.
+ */
+static int sleepy_request_firmware(const struct firmware **fw, 
+		const char *name, struct device *dev)

Review

Quoted 6 lines

(quoted diff) +6 -0

+{
+	if (request_firmware(fw, name, dev) == 0)
+		return 0;
+	msleep(1000);
+	return request_firmware(fw, name, dev);
+}

egad. Is there no better way?

this code looks like a 'orrible hack to work around a common problem with USB modem's of this type: if the modem is plugged in while the system boots, the driver may look for firmware before the filesystem holding the firmware is mounted; I guess the delay usually gives the filesystem enough time to be mounted. I'm told that the correct solution is to stick the firmware in an initramfs as well.

Why can't we request the firmware again when the device is first used, if it wasn't present when the driver was first loaded?

Hi Andrew,

this code looks like a 'orrible hack to work around a common problem with USB modem's of this type: if the modem is plugged in while the system boots, the driver may look for firmware before the filesystem

Review

Quoted 8 lines · matthieu castet

...

(quoted diff) +7 -0

+static int request_cmvs(struct uea_softc *sc,
+		 struct uea_cmvs **cmvs, const struct firmware **fw)
+{
+	int ret, size;
+	u8 *data;
+	char *file;
+	char cmv_name[256] = FW_DIR;

That's rather a lot of stack. Can this be made static, of kmalloced?

Review

Quoted 2 lines

(quoted diff) +2 -0

+
+	*cmvs = (struct uea_cmvs *)(data + 1);

That's a bit rude - asking the compiler to perform a structure copy from an odd address. memcpy() would be saner.

Review

Quoted 6 lines

...

(quoted diff) +5 -0

+/**
+ * uea_read_proc : /proc information
+ */
+static int uea_read_proc(char *page, 
+		char **start, off_t off, int count, int *eof, void *data)

People get shouted at for adding /proc handlers. Greg may have thoughts...

Please comment and consider for inclusion.

+ *
+ * This software is available to you under a choice of one of two
+ * licenses. You may choose to be licensed under the terms of the GNU
+ * General Public License (GPL) Version 2, available from the file
+ * COPYING in the main directory of this source tree, or the
+ * BSD license below:
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:

+#define EAGLEUSBVERSION "ueagle-svn $Id: ueagle.c 141 2005-09-03 20:12:24Z matc $"

+/* we need to use semaphore until sysfs and removable devices is fixed
+ * the problem is explained on http://marc.theaimsgroup.com/?t=112006484100003
+ */

+#define PACKED __attribute__ ((packed))

Hi Duncan,

Quoted 6 lines · Duncan Sands

Hi Andrew,

this code looks like a 'orrible hack to work around a common problem with USB modem's of this type: if the modem is plugged in while the system boots, the driver may look for firmware before the filesystem

No, it wasn't the problem, even when loading with insmod/modprobe the timeout occurs on some configurations. For example on
http://atm.eagle-usb.org/wakka.php?wiki=TestUEagleAtmBaud123, you could see the 'firmware ueagle-atm/eagleIII.fw is not available' error.

It is only happen for pre-firmware modem (uea_load_firmware) ie where we just do a request_firmware in the probe without any initialisation before. So the problem seems to appear when we do a request_firmware too early in the usb_probe.

Quoted 8 lines

Review

Quoted 3 lines

(quoted diff) +2 -0

+
+	*cmvs = (struct uea_cmvs *)(data + 1);

That's a bit rude - asking the compiler to perform a structure copy from an odd address. memcpy() would be saner.

Could you elaborate a bit more ?
I don't see where there is a copy.
*cmvs is a pointer to the structure, not the structure. And when we parse the structure, we use get_unaligned functions.

Quoted 6 lines · Duncan Sands

this code looks like a 'orrible hack to work around a common problem with USB modem's of this type: if the modem is plugged in while the system boots, the driver may look for firmware before the filesystem holding the firmware is mounted; I guess the delay usually gives the filesystem enough time to be mounted. I'm told that the correct solution is to stick the firmware in an initramfs as well.

Why can't we request the firmware again when the device is first used, if it wasn't present when the driver was first loaded?

we could do this for the speedtouch - in fact we used to do this: when someone tried to open a connection, we loaded the firmware if it hadn't been loaded yet. The problem is with other modems, like the connexant access runner, for which you can't get all the info needed to create an ATM device before the firmware is loaded (the MAC address for example).

Quoted 3 lines

this code looks like a 'orrible hack to work around a common problem with USB modem's of this type: if the modem is plugged in while the system boots, the driver may look for firmware before the filesystem

No, it wasn't the problem, even when loading with insmod/modprobe the timeout occurs on some configurations. For example on
http://atm.eagle-usb.org/wakka.php?wiki=TestUEagleAtmBaud123, you could see the 'firmware ueagle-atm/eagleIII.fw is not available' error.

It is only happen for pre-firmware modem (uea_load_firmware) ie where we just do a request_firmware in the probe without any initialisation before. So the problem seems to appear when we do a request_firmware too early in the usb_probe.

Quoted 2 lines

People get shouted at for adding /proc handlers. Greg may have thoughts...

Ok, we may be convert some values to sysfs. It would be nice if usbatm allow us to export some common value (margin, ...).

Quoted 6 lines

+ * sometime hotplug don't have time to give the firmware the
+ * first time, retry it.
+ */

drivers/usb/atm/ueagle-atm.c renamed from drivers/usb/atm.old/ueagle-atm.c +3 -0

+static int sleepy_request_firmware(const struct firmware **fw, 
+		const char *name, struct device *dev)
+{

drivers/usb/atm/ueagle-atm.c line 114

Quoted 5 lines

drivers/usb/atm/ueagle-atm.c renamed from drivers/usb/atm.old/ueagle-atm.c +5 -0

+	if (request_firmware(fw, name, dev) == 0)
+		return 0;
+	msleep(1000);
+	return request_firmware(fw, name, dev);
+}

No, use the async firmware download mode instead of this. That will solve all of your problems.

Quoted 6 lines · Duncan Sands

we could do this for the speedtouch - in fact we used to do this: when someone tried to open a connection, we loaded the firmware if it hadn't been loaded yet. The problem is with other modems, like the connexant access runner, for which you can't get all the info needed to create an ATM device before the firmware is loaded (the MAC address for example).

Don't we also have Ethernet devices like that -- where the MAC address doesn't get set until you bring the device up?

Can we get away with changing the MAC address later? Or is there other stuff we need earlier?

Quoted 6 lines

Quoted 6 lines

+ * sometime hotplug don't have time to give the firmware the
+ * first time, retry it.
+ */

drivers/usb/atm/ueagle-atm.c renamed from drivers/usb/atm.old/ueagle-atm.c +3 -0

+static int sleepy_request_firmware(const struct firmware **fw, 
+		const char *name, struct device *dev)
+{

Quoted 8 lines

drivers/usb/atm/ueagle-atm.c line 114

Quoted 5 lines

drivers/usb/atm/ueagle-atm.c renamed from drivers/usb/atm.old/ueagle-atm.c +5 -0

+	if (request_firmware(fw, name, dev) == 0)
+		return 0;
+	msleep(1000);
+	return request_firmware(fw, name, dev);
+}

No, use the async firmware download mode instead of this. That will solve all of your problems.

Hi Greg, it looks like you understand what the problem is here. Could you please explain to us lesser mortals ;)

Quoted 15 lines

Quoted 14 lines

drivers/usb/atm/ueagle-atm.c line 114

Quoted 11 lines

+ * sometime hotplug don't have time to give the firmware the
+ * first time, retry it.
+ */

drivers/usb/atm/ueagle-atm.c renamed from drivers/usb/atm.old/ueagle-atm.c +8 -0

+static int sleepy_request_firmware(const struct firmware **fw, 
+		const char *name, struct device *dev)
+{
+	if (request_firmware(fw, name, dev) == 0)
+		return 0;
+	msleep(1000);
+	return request_firmware(fw, name, dev);
+}

No, use the async firmware download mode instead of this. That will solve all of your problems.

Quoted 2 lines

Hi Greg, it looks like you understand what the problem is here. Could you please explain to us lesser mortals ;)

If you use the async mode, there is no timeout. When userspace gets around to giving you the firmware, then you continue on with the rest of your device initialization (don't block the usb probe function though.)

Am Mittwoch, 2. November 2005 09:03 schrieb Greg KH:

Quoted 19 lines · Duncan Sands

Quoted 17 lines

Quoted 6 lines

Quoted 6 lines

+ * sometime hotplug don't have time to give the firmware the
+ * first time, retry it.
+ */

drivers/usb/atm/ueagle-atm.c renamed from drivers/usb/atm.old/ueagle-atm.c +3 -0

+static int sleepy_request_firmware(const struct firmware **fw, 
+		const char *name, struct device *dev)
+{

Quoted 8 lines

drivers/usb/atm/ueagle-atm.c line 114

Quoted 5 lines

drivers/usb/atm/ueagle-atm.c renamed from drivers/usb/atm.old/ueagle-atm.c +5 -0

+	if (request_firmware(fw, name, dev) == 0)
+		return 0;
+	msleep(1000);
+	return request_firmware(fw, name, dev);
+}

No, use the async firmware download mode instead of this. That will solve all of your problems.

Hi Greg, it looks like you understand what the problem is here. Could you please explain to us lesser mortals ;)

Quoted 3 lines

If you use the async mode, there is no timeout. When userspace gets around to giving you the firmware, then you continue on with the rest of your device initialization (don't block the usb probe function though.)

How would you handle errors in setting up the device?
A driver cannot reject a device after probe, yet you need to handle errors appearing only after the firmware is in the device.

Quoted 6 lines · Duncan Sands

this code looks like a 'orrible hack to work around a common problem with USB modem's of this type: if the modem is plugged in while the system boots, the driver may look for firmware before the filesystem holding the firmware is mounted; I guess the delay usually gives the filesystem enough time to be mounted. I'm told that the correct solution is to stick the firmware in an initramfs as well.

Why can't we request the firmware again when the device is first used, if it wasn't present when the driver was first loaded?

Quoted 10 lines · David Woodhouse

Quoted 6 lines · Duncan Sands

this code looks like a 'orrible hack to work around a common problem with USB modem's of this type: if the modem is plugged in while the system boots, the driver may look for firmware before the filesystem holding the firmware is mounted; I guess the delay usually gives the filesystem enough time to be mounted. I'm told that the correct solution is to stick the firmware in an initramfs as well.

Why can't we request the firmware again when the device is first used, if it wasn't present when the driver was first loaded?

Because the firmware loading can take long, and apps may legitimately give up opening the device after a timeout.

Besides, it doesn't look logical. An uninitialized device is not particularly useful for anything but initialization. You don't create, say, a network device for your ethernet card until you're finished with its PCI setup, do you?

I think the async firmware loading can do the job nicely, in a generic manner. BTW the usbatm drivers do it already (wasn't it you who implemented it? :), long before request_firmware_nowait() was available. So it's only a matter of tools adjusting, which seems to be going on.

Quoted 3 lines

+/* we need to use semaphore until sysfs and removable devices is fixed
+ * the problem is explained on http://marc.theaimsgroup.com/?t=112006484100003
+ */

This is the proper fix, why do you think it should be fixed in the driver core?

Quoted 1 line · matthieu castet

Please comment and consider for inclusion.

I need a "Signed-off-by:" line in order to be able to add it. Care to redo things based on the comments you have had and resend it with this line?

Quoted 10 lines

+ *
+ * This software is available to you under a choice of one of two
+ * licenses. You may choose to be licensed under the terms of the GNU
+ * General Public License (GPL) Version 2, available from the file
+ * COPYING in the main directory of this source tree, or the
+ * BSD license below:
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:

<snip> You don't need the whole GPL 2 copy here, just put the first paragraph you have before this one in.

Quoted 8 lines

drivers/usb/atm/ueagle-atm.c renamed from drivers/usb/atm.old/ueagle-atm.c +8 -0

+/*
+ * sometime hotplug don't have time to give the firmware the
+ * first time, retry it.
+ */
+static int sleepy_request_firmware(const struct firmware **fw, 
+		const char *name, struct device *dev)
+{
+	if (request_firmware(fw, name, dev) == 0)

drivers/usb/atm/ueagle-atm.c line 114

Quoted 4 lines

drivers/usb/atm/ueagle-atm.c renamed from drivers/usb/atm.old/ueagle-atm.c +4 -0

+		return 0;
+	msleep(1000);
+	return request_firmware(fw, name, dev);
+}

No, use the async firmware download mode instead of this. That will solve all of your problems.

Quoted 3 lines

+/* we need to use semaphore until sysfs and removable devices is fixed
+ * the problem is explained on http://marc.theaimsgroup.com/?t=112006484100003
+ */

This is the proper fix, why do you think it should be fixed in the driver core?

drivers/usb/atm/ueagle-atm.h

Quoted 4 lines

diff -rNu -x '*.ko*' -x '*.mod*' -x '*.o*' linux-2.6.14/drivers/usb/atm.old/ueagle-atm.h linux-2.6.14/drivers/usb/atm/ueagle-atm.h

drivers/usb/atm/ueagle-atm.h renamed from drivers/usb/atm.old/ueagle-atm.h +0 -0

Why do you need a header file for a single .c file?

Quoted 1 line

+#define PACKED __attribute__ ((packed))

No, spell it out please.

drivers/usb/atm/ueagle-atm.h line 276

Quoted 10 lines

drivers/usb/atm/ueagle-atm.h renamed from drivers/usb/atm.old/ueagle-atm.h +10 -0

+/* structure describing a block within a DSP page */
+typedef struct {
+	__le16 wHdr;
+#define UEA_BIHDR 0xabcd
+	__le16 wAddress;
+	__le16 wSize;
+	__le16 wOvlOffset;
+	__le16 wOvl;		/* overlay */
+	__le16 wLast;
+} PACKED block_info_t;

Do not create new typedefs. Please get rid of all of them.

Hi Greg,

Quoted 9 lines

Quoted 9 lines

drivers/usb/atm/ueagle-atm.c renamed from drivers/usb/atm.old/ueagle-atm.c +9 -0

+/*
+ * sometime hotplug don't have time to give the firmware the
+ * first time, retry it.
+ */
+static int sleepy_request_firmware(const struct firmware **fw, 
+        const char *name, struct device *dev)
+{
+    if (request_firmware(fw, name, dev) == 0)
+        return 0;

Quoted 10 lines

drivers/usb/atm/ueagle-atm.c line 114

Quoted 3 lines

drivers/usb/atm/ueagle-atm.c renamed from drivers/usb/atm.old/ueagle-atm.c +3 -0

+    msleep(1000);
+    return request_firmware(fw, name, dev);
+}

No, use the async firmware download mode instead of this. That will solve all of your problems.

Thanks, but does userspace will retry if it fails the first time ?
The device needs the firmware quickly and after 3-5 seconds without it, it goes berserk.

Quoted 16 lines · matthieu castet

Hi Duncan,

Quoted 6 lines · Duncan Sands

Hi Andrew,

this code looks like a 'orrible hack to work around a common problem with USB modem's of this type: if the modem is plugged in while the system boots, the driver may look for firmware before the filesystem

No, it wasn't the problem, even when loading with insmod/modprobe the timeout occurs on some configurations. For example on
http://atm.eagle-usb.org/wakka.php?wiki=TestUEagleAtmBaud123, you could see the 'firmware ueagle-atm/eagleIII.fw is not available' error.

Quoted 5 lines

It is only happen for pre-firmware modem (uea_load_firmware) ie where we just do a request_firmware in the probe without any initialisation before. So the problem seems to appear when we do a request_firmware too early in the usb_probe.

Can you please work out exactly what's happening and come up with a more solid solution than msleep(1)?

Am Mittwoch, 2. November 2005 09:03 schrieb Greg KH:

Quoted 19 lines · Duncan Sands

Quoted 17 lines

Quoted 6 lines

Quoted 6 lines

+ * sometime hotplug don't have time to give the firmware the
+ * first time, retry it.
+ */

drivers/usb/atm/ueagle-atm.c renamed from drivers/usb/atm.old/ueagle-atm.c +3 -0

+static int sleepy_request_firmware(const struct firmware **fw, 
+		const char *name, struct device *dev)
+{

Quoted 8 lines

drivers/usb/atm/ueagle-atm.c line 114

Quoted 5 lines

drivers/usb/atm/ueagle-atm.c renamed from drivers/usb/atm.old/ueagle-atm.c +5 -0

+	if (request_firmware(fw, name, dev) == 0)
+		return 0;
+	msleep(1000);
+	return request_firmware(fw, name, dev);
+}

No, use the async firmware download mode instead of this. That will solve all of your problems.

Hi Greg, it looks like you understand what the problem is here. Could you please explain to us lesser mortals ;)

Quoted 3 lines

If you use the async mode, there is no timeout. When userspace gets around to giving you the firmware, then you continue on with the rest of your device initialization (don't block the usb probe function though.)

How would you handle errors in setting up the device?
A driver cannot reject a device after probe, yet you need to handle errors appearing only after the firmware is in the device.

Quoted 24 lines · Oliver Neukum

Am Mittwoch, 2. November 2005 09:03 schrieb Greg KH:

Quoted 22 lines · Duncan Sands

Quoted 15 lines

Quoted 6 lines

Quoted 6 lines

+ * sometime hotplug don't have time to give the firmware the
+ * first time, retry it.
+ */

drivers/usb/atm/ueagle-atm.c renamed from drivers/usb/atm.old/ueagle-atm.c +3 -0

+static int sleepy_request_firmware(const struct firmware **fw, 
+		const char *name, struct device *dev)
+{

Quoted 8 lines

drivers/usb/atm/ueagle-atm.c line 114

Quoted 5 lines

drivers/usb/atm/ueagle-atm.c renamed from drivers/usb/atm.old/ueagle-atm.c +5 -0

+	if (request_firmware(fw, name, dev) == 0)
+		return 0;
+	msleep(1000);
+	return request_firmware(fw, name, dev);
+}

No, use the async firmware download mode instead of this. That will solve all of your problems.

Quoted 2 lines

Hi Greg, it looks like you understand what the problem is here. Could you please explain to us lesser mortals ;)

If you use the async mode, there is no timeout. When userspace gets around to giving you the firmware, then you continue on with the rest of your device initialization (don't block the usb probe function though.)

Quoted 3 lines

How would you handle errors in setting up the device?
A driver cannot reject a device after probe, yet you need to handle errors appearing only after the firmware is in the device.

Isn't that the case anyway with the sync version?

After all, sync loading of firmware from the probe method is unacceptable, since it can block khubd for a long time (also, if the firmware lives on a USB device that gets disconnected just as probe for the device that loads firmware is called, or some variation of this theme, couldn't horrible blockage happen?).

Quoted 13 lines

Quoted 10 lines

+ *
+ * This software is available to you under a choice of one of two
+ * licenses. You may choose to be licensed under the terms of the GNU
+ * General Public License (GPL) Version 2, available from the file
+ * COPYING in the main directory of this source tree, or the
+ * BSD license below:
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:

Quoted 3 lines

<snip> You don't need the whole GPL 2 copy here, just put the first paragraph you have before this one in.

The paragraph you quote is the BSD licence, and point 1 is :
Redistributions of source code must retain the above copyright
* notice unmodified, this list of conditions, and the following
* disclaimer

So could I remove it ?

Quoted 11 lines

Quoted 6 lines

diff -rNu -x '*.ko*' -x '*.mod*' -x '*.o*' linux-2.6.14/drivers/usb/atm.old/ueagle-atm.h linux-2.6.14/drivers/usb/atm/ueagle-atm.h
--- linux-2.6.14/drivers/usb/atm.old/ueagle-atm.h 1970-01-01
01:00:00.000000000 +0100
+++ linux-2.6.14/drivers/usb/atm/ueagle-atm.h 2005-10-30
00:25:27.000000000 +0200

Why do you need a header file for a single .c file?

I think it makes things cleaner. I even like the bsd style where there is an header for reg (hardware values) and an other for val (driver structures).

- For the license stuff, all the dual bsd/gpl drivers I saw in the kernel tree have the complete bsd header.

- For the header file I prefer a separate header file, but if Linux policy is to merge header and source file, that's fine.

Quoted 20 lines · matthieu castet

Hi Greg,

Quoted 19 lines

drivers/usb/atm/ueagle-atm.c line 114

Quoted 12 lines

drivers/usb/atm/ueagle-atm.c renamed from drivers/usb/atm.old/ueagle-atm.c +12 -0

+/*
+ * sometime hotplug don't have time to give the firmware the
+ * first time, retry it.
+ */
+static int sleepy_request_firmware(const struct firmware **fw, 
+        const char *name, struct device *dev)
+{
+    if (request_firmware(fw, name, dev) == 0)
+        return 0;
+    msleep(1000);
+    return request_firmware(fw, name, dev);
+}

No, use the async firmware download mode instead of this. That will solve all of your problems.

Quoted 4 lines

Thanks, but does userspace will retry if it fails the first time ? The device needs the firmware quickly and after 3-5 seconds without it, it goes berserk.

In request_firmware_nowait, when kernel_thread failed, where fw_work is freed ?
Aren't there a memleack ?

Hi Greg,

thanks for your review.

Quoted 10 lines · Greg KH

Quoted 1 line · matthieu castet

Please comment and consider for inclusion.

I need a "Signed-off-by:" line in order to be able to add it. Care to redo things based on the comments you have had and resend it with this line?

no problem ;)

Quoted 12 lines

Quoted 10 lines

+ *
+ * This software is available to you under a choice of one of two
+ * licenses. You may choose to be licensed under the terms of the GNU
+ * General Public License (GPL) Version 2, available from the file
+ * COPYING in the main directory of this source tree, or the
+ * BSD license below:
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:

Quoted 3 lines

<snip> You don't need the whole GPL 2 copy here, just put the first paragraph you have before this one in.

The paragraph you quote is the BSD licence, and point 1 is :
Redistributions of source code must retain the above copyright
* notice unmodified, this list of conditions, and the following
* disclaimer

So could I remove it ?

Quoted 8 lines

Quoted 8 lines

drivers/usb/atm/ueagle-atm.c renamed from drivers/usb/atm.old/ueagle-atm.c +8 -0

+/*
+ * sometime hotplug don't have time to give the firmware the
+ * first time, retry it.
+ */
+static int sleepy_request_firmware(const struct firmware **fw, 
+		const char *name, struct device *dev)
+{
+	if (request_firmware(fw, name, dev) == 0)

Quoted 10 lines

drivers/usb/atm/ueagle-atm.c line 114

Quoted 4 lines

drivers/usb/atm/ueagle-atm.c renamed from drivers/usb/atm.old/ueagle-atm.c +4 -0

+		return 0;
+	msleep(1000);
+	return request_firmware(fw, name, dev);
+}

No, use the async firmware download mode instead of this. That will solve all of your problems.

Thanks, but does userspace will retry if it fails the first time ? The device needs the firmware quickly and after 3-5 seconds without it, it goes berserk.

Quoted 6 lines

Quoted 4 lines

+/* we need to use semaphore until sysfs and removable devices is fixed
+ * the problem is explained on
http://marc.theaimsgroup.com/?t=112006484100003
+ */

Quoted 3 lines

This is the proper fix, why do you think it should be fixed in the driver core?

I don't remember, but aren't any possible race in sysfs code ? In the read, after the up, the usb_disconnect is scheduled, and call device_remove_file. Is that ok for the sysfs code to be still in the read code ?

An other case : a process open a file, and start a read. Before the down , the usb_disconnect is scheduled and the module is removed. What will do the read, run code from the removed code ?

Quoted 11 lines

Quoted 7 lines

diff -rNu -x '*.ko*' -x '*.mod*' -x '*.o*'
linux-2.6.14/drivers/usb/atm.old/ueagle-atm.h
linux-2.6.14/drivers/usb/atm/ueagle-atm.h
--- linux-2.6.14/drivers/usb/atm.old/ueagle-atm.h 1970-01-01
01:00:00.000000000 +0100
+++ linux-2.6.14/drivers/usb/atm/ueagle-atm.h 2005-10-30
00:25:27.000000000 +0200

Why do you need a header file for a single .c file?

I think it makes things cleaner. I even like the bsd style where there is an header for reg (hardware values) and an other for val (driver structures).

Quoted 2 lines

Thanks, but does userspace will retry if it fails the first time ?
The device needs the firmware quickly and after 3-5 seconds without it, it goes berserk.

That sounds like a pretty broken device :)

This isn't BSD :)

It's ok, as long as it is local, and it is what you want to do. I don't have a strong feeling toward it.

Hi,

here the corrected version of ueagle-atm.

The comments of Adrew Morton and Greg KH have been applied.
We also fix a bug in the check_dsp routine (reported on our mailling list) and kill some unsued code.

Signed-off-by Matthieu CASTET <[email protected]>