LinuxLists.cc - [PATCH] Eagle and ADI 930 usb adsl modem driver

[permalink] [raw]

Subject: Re: [PATCH] Eagle and ADI 930 usb adsl modem driver

Hi Andrew,

> > +/*
> > + * 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);
> > +}
>
> 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. That's a
pity: it would be nice if users could just dump the firmware in an
appropriate directory and have everything work [*]. As it is, they
also have to regenerate an initramfs.

Ciao,

Duncan.

[*] For legal reasons, users usually have to download and install
the firmware themselves. For the speedtouch modems I don't know
of any distribution which comes with the firmware preinstalled.

2005-11-01 13:03:40

by David Woodhouse

[permalink] [raw]

Subject: Re: [PATCH] Eagle and ADI 930 usb adsl modem driver

On Tue, 2005-11-01 at 13:40 +0100, Duncan Sands wrote:
> 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?

--
dwmw2

2005-11-01 13:12:48

by Marco d'Itri

[permalink] [raw]

Subject: Re: [PATCH] Eagle and ADI 930 usb adsl modem driver

On Nov 01, David Woodhouse <[email protected]> wrote:

> 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?
For a start, because currently there is no device to use until the
firmware has been loaded.

If people really think that this is a problem which needs to be solved
then maybe a better solution would be to extend the $DEVPATH/loading to
allow loading the firmware at any time, even asyncronously after the
timeout.

--
ciao,
Marco

Attachments:

(No filename) (519.00 B)
signature.asc (189.00 B)
Digital signature Download all attachments

2005-11-01 13:49:09

[permalink] [raw]

Subject: Re: [PATCH] Eagle and ADI 930 usb adsl modem driver

Hi Duncan,

Duncan Sands wrote:
> 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.

Matthieu

2005-11-01 14:08:10

[permalink] [raw]

Subject: Re: [PATCH] Eagle and ADI 930 usb adsl modem driver

Hi Andrew,

thanks for the review.

Andrew Morton wrote:
> matthieu castet <[email protected]> wrote:
>

>>...
>>+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?
>
>
I think we'll made it static.

>>+
>>+ *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.

>>...
>>+/**
>>+ * 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...
>
Ok, we may be convert some values to sysfs. It would be nice if usbatm
allow us to export some common value (margin, ...).

Matthieu

2005-11-02 05:11:19

[permalink] [raw]

Subject: Re: [PATCH] Eagle and ADI 930 usb adsl modem driver

On Sun, Oct 30, 2005 at 12:37:41AM +0200, matthieu castet wrote:
> 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?

> + *
> + * 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.

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

We don't use $Id within the kernel tree, please remove this.

> +static int uea_read_proc(char *page, char **start, off_t off, int count,
> + int *eof, void *data);

No new proc files will be added for drivers, please use sysfs instead
(with only one file per value.)

> +/*
> + * 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.

> +/* 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?

> +#define UEA_DEVICE(vid, pid, info) \
> + {USB_DEVICE((vid), (pid)), .driver_info = (info)}

Why create a macro for such a simple thing? That's not needed.

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

> +#define PACKED __attribute__ ((packed))

No, spell it out please.

> +/* 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.

thanks,

greg k-h

2005-11-02 06:31:32

by Andrew Morton

[permalink] [raw]

Subject: Re: [PATCH] Eagle and ADI 930 usb adsl modem driver

matthieu castet <[email protected]> wrote:
>
> Hi Duncan,
>
> Duncan Sands wrote:
> > 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.
>

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

Because other drivers may hit this problem (whatever it is) and fixes in
core kernel might be needed. If we just work around stuff, core kernel
remains unfixed...

2005-11-02 06:34:42

by Andrew Morton

[permalink] [raw]

Subject: Re: [PATCH] Eagle and ADI 930 usb adsl modem driver

matthieu castet <[email protected]> wrote:
>
> >>+
> >>+ *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.
>
>

Ah, I misread the code.

2005-11-02 07:43:08

[permalink] [raw]

Subject: Re: [PATCH] Eagle and ADI 930 usb adsl modem driver

Hi David,

On Tuesday 1 November 2005 14:04, David Woodhouse wrote:
> On Tue, 2005-11-01 at 13:40 +0100, Duncan Sands wrote:
> > 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).

Ciao,

D.

2005-11-02 07:45:21

by David Woodhouse

[permalink] [raw]

Subject: Re: [PATCH] Eagle and ADI 930 usb adsl modem driver

On Wed, 2005-11-02 at 08:42 +0100, Duncan Sands wrote:
> 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?

--
dwmw2

2005-11-02 07:46:03

[permalink] [raw]

Subject: Re: [PATCH] Eagle and ADI 930 usb adsl modem driver

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

That sounds pretty strange. Maybe when probe is called the driver model
device (sysfs) is not completely setup, in any case not enough to support
firmware loading?

Ciao,

Duncan.

2005-11-02 07:47:08

[permalink] [raw]

Subject: Re: [PATCH] Eagle and ADI 930 usb adsl modem driver

> > 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, ...).

Yes it would be nice. Patches welcome :)

D.

2005-11-02 07:54:25

[permalink] [raw]

Subject: Re: [PATCH] Eagle and ADI 930 usb adsl modem driver

> > + * 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.

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

Thanks,

Duncan.

2005-11-02 08:02:29

[permalink] [raw]

Subject: Re: [PATCH] Eagle and ADI 930 usb adsl modem driver

On Wednesday 2 November 2005 08:45, David Woodhouse wrote:
> On Wed, 2005-11-02 at 08:42 +0100, Duncan Sands wrote:
> > 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?

Hi David, it's only the MAC address. I didn't check carefully, but I'm pretty
sure that in general the MAC address is the only device dependant info needed
to setup an ATM device. But isn't changing the MAC address later a horrible
hack that is sure to break stuff?

Duncan.

2005-11-02 08:04:52

[permalink] [raw]

Subject: Re: [PATCH] Eagle and ADI 930 usb adsl modem driver

On Wed, Nov 02, 2005 at 08:54:22AM +0100, Duncan Sands wrote:
> > > + * 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.
>
> 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.)

Everyone should switch to that interface, then we would not have any
timeout issues anymore...

thanks,

greg k-h

2005-11-02 08:44:45

by Oliver Neukum

[permalink] [raw]

Subject: Re: [linux-usb-devel] Re: [PATCH] Eagle and ADI 930 usb adsl modem driver

Am Mittwoch, 2. November 2005 09:03 schrieb Greg KH:
> On Wed, Nov 02, 2005 at 08:54:22AM +0100, Duncan Sands wrote:
> > > > + * 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.
> >
> > 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.)

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.

Regards
Oliver

2005-11-02 08:53:00

[permalink] [raw]

Subject: Re: [linux-usb-devel] Re: [PATCH] Eagle and ADI 930 usb adsl modem driver

On Wednesday 2 November 2005 09:45, Oliver Neukum wrote:
> Am Mittwoch, 2. November 2005 09:03 schrieb Greg KH:
> > On Wed, Nov 02, 2005 at 08:54:22AM +0100, Duncan Sands wrote:
> > > > > + * 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.
> > >
> > > 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.)
>
> 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?).

Ciao,

D.

2005-11-02 10:49:18

by Roman Kagan

[permalink] [raw]

Subject: Re: [PATCH] Eagle and ADI 930 usb adsl modem driver

On Tue, Nov 01, 2005 at 01:04:02PM +0000, David Woodhouse wrote:
> On Tue, 2005-11-01 at 13:40 +0100, Duncan Sands wrote:
> > 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.

Roman.

2005-11-02 11:01:22

[permalink] [raw]

Subject: Re: [PATCH] Eagle and ADI 930 usb adsl modem driver

Hi Roman, glad to see you're still alive!

On Wednesday 2 November 2005 11:46, Roman Kagan wrote:
> On Tue, Nov 01, 2005 at 01:04:02PM +0000, David Woodhouse wrote:
> > On Tue, 2005-11-01 at 13:40 +0100, Duncan Sands wrote:
> > > 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.

I can't help feeling that it is wrong to add ad-hoc code to drivers (such
as: if the firmware wasn't there, try to load it again later) in an attempt
to work around what is, in the end, a userspace configuration problem. The
fact that configuring userspace correctly seems to be tricky is sad, but not
the driver's problem.

I don't mind using request_firmware_nowait by the way. The lack of a
timeout is no problem as long as we make it possible for the user to shoot
the firmware loading down by sending a signal.

Ciao,

Duncan.

PS: On the other hand, users are feeling the pain, which means I get to feel
their pain, which tempts me to hack in a workaround ;)

2005-11-02 15:56:09

by Alan Stern

[permalink] [raw]

Subject: Re: [linux-usb-devel] Re: [PATCH] Eagle and ADI 930 usb adsl modem driver

On Tue, 1 Nov 2005, Greg KH wrote:

> > +/* 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?

I missed the earlier discussion about this when it appeared on lkml.

This is no doubt a widespread problem, and it should be brought to many
people's attention. Greg, can you think of any good way to make this more
visible? Maybe a short piece in Linux Journal combined with a more
eye-catching $SUBJECT in lkml?

Maybe this could be combined with a brief discussion of the open-remove
race as well (and the use of BKL to help resolve it).

Alan Stern

2005-11-02 20:15:54

[permalink] [raw]

Subject: Re: [PATCH] Eagle and ADI 930 usb adsl modem driver

Hi Greg,

thanks for your review.

Greg KH wrote:
> On Sun, Oct 30, 2005 at 12:37:41AM +0200, matthieu castet wrote:
>
>>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 ;)
>>+ *
>>+ * 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.
>
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 ?

>>+/*
>>+ * 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.
>
>
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.

>>+/* 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?
>
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 ?

>
>>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).

>>+#define PACKED __attribute__ ((packed))
>
>
> No, spell it out please.
>
>
>>+/* 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.
It comes from bsd driver, it will be cleaned.

thanks,

Matthieu

2005-11-02 21:18:14

[permalink] [raw]

Subject: Re: [PATCH] Eagle and ADI 930 usb adsl modem driver

matthieu castet wrote:
> Hi Greg,
>>> +/*
>>> + * 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.
>>
>>
> 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 ?

Matthieu

2005-11-02 23:30:23

[permalink] [raw]

Subject: Re: [linux-usb-devel] Re: [PATCH] Eagle and ADI 930 usb adsl modem driver

On Wed, Nov 02, 2005 at 09:45:28AM +0100, Oliver Neukum wrote:
> Am Mittwoch, 2. November 2005 09:03 schrieb Greg KH:
> > On Wed, Nov 02, 2005 at 08:54:22AM +0100, Duncan Sands wrote:
> > > > > + * 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.
> > >
> > > 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.)
>
> 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.

Yes, you can disconnect from a device after you accept it. And you
_know_ you want this device anyway, as it is of the type you handle. If
something bad happens, it's ok to still have the device "claimed" as
what else would you be able to do with it? :)

thanks,

greg k-h

2005-11-02 23:30:48

[permalink] [raw]

Subject: Re: [linux-usb-devel] Re: [PATCH] Eagle and ADI 930 usb adsl modem driver

On Wed, Nov 02, 2005 at 09:52:56AM +0100, Duncan Sands wrote:
> On Wednesday 2 November 2005 09:45, Oliver Neukum wrote:
> > Am Mittwoch, 2. November 2005 09:03 schrieb Greg KH:
> > > On Wed, Nov 02, 2005 at 08:54:22AM +0100, Duncan Sands wrote:
> > > > > > + * 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.
> > > >
> > > > 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.)
> >
> > 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?

Yes.

> 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?).

Yes it could. That's why you should use the async version :)

One of these days I'll start multi-threading the device probe stuff, and
it will not be that big of a deal...[1]

thanks,

greg k-h

[1] Yes, I know the usb core and drivers will not expect this, and work
will be needed to get this working properly.

2005-11-02 23:30:22

[permalink] [raw]

Subject: Re: [PATCH] Eagle and ADI 930 usb adsl modem driver

On Wed, Nov 02, 2005 at 04:29:58PM +1100, Andrew Morton wrote:
> matthieu castet <[email protected]> wrote:
> >
> > Hi Duncan,
> >
> > Duncan Sands wrote:
> > > 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.
> >
>
> Can you please work out exactly what's happening and come up with a more
> solid solution than msleep(1)?

The fix is to use the async firmware interface, no sleeping or timeouts
needed.

thanks,

greg k-h

2005-11-06 18:44:03

[permalink] [raw]

Subject: Re: [PATCH] Eagle and ADI 930 usb adsl modem driver

Hi Greg,

matthieu castet wrote:

>>> + *
>>> + * 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.
>>
> 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 ?
>
>
>>
>>> 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).
>

We patched our driver with the comments sent, but we still don't know
what to do with this 2 points :
- 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.

Regards,

Matthieu

2005-11-07 17:48:16

[permalink] [raw]

Subject: Re: [PATCH] Eagle and ADI 930 usb adsl modem driver

On Sun, Nov 06, 2005 at 07:44:10PM +0100, matthieu castet wrote:
> - For the license stuff, all the dual bsd/gpl drivers I saw in the
> kernel tree have the complete bsd header.

That's fine.

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

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.

thanks,

greg k-h

2005-11-07 17:48:45

[permalink] [raw]

Subject: Re: [PATCH] Eagle and ADI 930 usb adsl modem driver

On Wed, Nov 02, 2005 at 09:15:58PM +0100, matthieu castet wrote:
> Hi Greg,
>
> thanks for your review.
>
> Greg KH wrote:
> >On Sun, Oct 30, 2005 at 12:37:41AM +0200, matthieu castet wrote:
> >
> >>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 ;)
> >>+ *
> >>+ * 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.
> >
> 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 ?

Ugh, you are right, I missed that this was BSD also, sorry. It's fine.

> >>+/*
> >>+ * 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.
> >
> >
> 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 :)

I don't know, have your own timer that disconnects it after X seconds if
you haven't gotten the firmware yet? Don't rely on userspace getting
around to you real quickly, as we have seen lots of problems with
drivers relying on that timeout.

> >>+/* 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?
> >
> 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 ?

Depends on what that code does.

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

Again, depends on how your code is structured, and what you are
referencing in that read code.

> >>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).

This isn't BSD :)

thanks,

greg k-h

2005-11-07 17:48:19

[permalink] [raw]

Subject: Re: [PATCH] Eagle and ADI 930 usb adsl modem driver

On Wed, Nov 02, 2005 at 10:18:13PM +0100, matthieu castet wrote:
> matthieu castet wrote:
> >Hi Greg,
> >>>+/*
> >>>+ * 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.
> >>
> >>
> >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 ?

I really do not know, as I have not looked at that code. If you see
problems in it, please feel free to fix it up, as there is no living
maintainer for it anymore :(

thanks,

greg k-h

2005-11-07 18:47:50

[permalink] [raw]

Subject: Re: [PATCH] Eagle and ADI 930 usb adsl modem driver

Hi Greg,

Greg KH wrote:

>>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 :)
If it was only that (don't work in bulk mode with down rate > 3Mbps ;
empty iso urb report errors, ...)...

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

I finally merge them like other usbatm driver did.

The corrected version is ready, I will wait some time in order others
developers could do final checking.
I will send it this evening or tomorrow.

Thanks

Matthieu

2005-11-07 22:27:06

[permalink] [raw]

Subject: Re: [PATCH] Eagle and ADI 930 usb adsl modem driver

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

Attachments:

ueagle-atm.diff (47.28 kB)

2005-11-07 23:02:20