From castet.matthieu at free.fr  Sat Oct 29 18:14:12 2005
From: castet.matthieu at free.fr (matthieu castet)
Date: Sat Oct 29 18:14:34 2005
Subject: iso support
Message-ID: <4363F434.3090706@free.fr>

Hi Ducnan,

I saw that you start implementing iso support in usbatm, that nice.

But why don't you use the interface we seem to agree before the holidays 
(option stuff) ?

It's break the API, mine wasn't.

Also how can I integrate support for eagle bugs now ?


Cheers,

Matthieu

From castet.matthieu at free.fr  Sat Oct 29 18:55:34 2005
From: castet.matthieu at free.fr (matthieu castet)
Date: Sat Oct 29 18:55:50 2005
Subject: iso support
In-Reply-To: <4363F434.3090706@free.fr>
References: <4363F434.3090706@free.fr>
Message-ID: <4363FDE6.40902@free.fr>

Hi,

matthieu castet wrote:
> Hi Ducnan,
> 
> 
> Also how can I integrate support for eagle bugs now ?
> 
as you include 2 things that were supported by option stuff, there only 
the -EILSEQ bug.

May be you can apply it for all modem ?

regards,

Matthieu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: usbatm.patch
Type: text/x-patch
Size: 605 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/usbatm/attachments/20051029/0c54a73c/usbatm.bin
From stf_xl at wp.pl  Sun Oct 30 14:15:13 2005
From: stf_xl at wp.pl (Stanislaw Gruszka)
Date: Sun Oct 30 13:08:29 2005
Subject: [PATCH] info to atm layer about broken connection
Message-ID: <200510302015.14047.stf_xl@wp.pl>

Hi,

Finish internet connection when modem is disconnect form usb port, 
additionally force root to disable connection before unloading 
subdriver module. Tested with pppoatm.

__
Staszek Gruszka 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch
Type: text/x-diff
Size: 1505 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/usbatm/attachments/20051030/c502002e/patch.bin
From duncan.sands at math.u-psud.fr  Sun Oct 30 15:00:43 2005
From: duncan.sands at math.u-psud.fr (Duncan Sands)
Date: Sun Oct 30 15:01:58 2005
Subject: [PATCH] info to atm layer about broken connection
In-Reply-To: <200510302015.14047.stf_xl@wp.pl>
References: <200510302015.14047.stf_xl@wp.pl>
Message-ID: <200510302100.44285.duncan.sands@math.u-psud.fr>

Hi Staszek, thanks for the patch, however I think this is the
wrong approach.  The right thing to do is to go through the list
of vccs and do vcc_release_async() on each one.  Also, as far
as I can see the use of try_module_get is pointless.  Why do
you think it is needed?

> Finish internet connection when modem is disconnect form usb port, 
> additionally force root to disable connection before unloading 
> subdriver module. Tested with pppoatm.

All the best,

Duncan.

From stf_xl at wp.pl  Sun Oct 30 16:44:09 2005
From: stf_xl at wp.pl (Stanislaw Gruszka)
Date: Sun Oct 30 15:37:21 2005
Subject: [PATCH] info to atm layer about broken connection
In-Reply-To: <200510302100.44285.duncan.sands@math.u-psud.fr>
References: <200510302015.14047.stf_xl@wp.pl>
	<200510302100.44285.duncan.sands@math.u-psud.fr>
Message-ID: <200510302244.09734.stf_xl@wp.pl>

Hi Duncan
> Hi Staszek, thanks for the patch, however I think this is the
> wrong approach.  The right thing to do is to go through the list
> of vccs and do vcc_release_async() on each one.  
vcc_release_async() don't work with pppoatm, I don't know why,
simply after disconnect modem, ppp demon still works 
and ifconfig command show me connection is ok.
Using vcc->push(vcc, NULL) kill pppd with
Modem hangup message in logs.

> Also, as far as I can see the use of try_module_get is pointless.  Why do
> you think it is needed?
It depends on approach, someone would like to finish connection when 
net driver module is unloaded, other one would like to prevent unloading 
module. I preffer second approach as is in (for example) pppoatm .

Adding try_module_get and module_put pair in subdriver atm_start() and atm_stop() 
propably block unload module anyway.

__
Regards
Staszek Gruszka

From castet.matthieu at free.fr  Sat Oct 29 18:37:41 2005
From: castet.matthieu at free.fr (matthieu castet)
Date: Mon Oct 31 02:18:07 2005
Subject: [PATCH]  Eagle and ADI 930 usb adsl modem driver
Message-ID: <4363F9B5.6010907@free.fr>

Hi,

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

The managing part was taken from bsd ueagle driver, other parts were
written from scratch.

The driver uses the in-kernel firmware loader :
- to load  a first usb firmware when the modem is in pre-firmware state
- to load the dsp firmware that are swapped in host memory.
- to load CMV (configuration and management variables) when the modem
boot. (We can't use options or sysfs for this as there many possible
values. See
https://mail.gna.org/public/eagleusb-dev/2005-04/msg00031.html for a
description of some)
- to load fpga code for 930 chipset.

The device had 4 endpoints :
* 2 for data (use by usbatm). The incoming
endpoint could be iso or bulk. The modem seems buggy and produce lot's
of atm errors when using it in bulk mode for speed > 3Mbps, so iso
endpoint is need for speed > 3Mbps. At the moment iso endpoint need a
patched usbatm library and for this reason is not included in this patch.

* One bulk endpoint for uploading dsp firmware

* One irq endpoint that notices the driver
    - if we need to upload a page of the dsp firmware
    - an ack for read or write CMV and the value (for the read case).

If order to make the driver cleaner, we design synchronous
(read|write)_cmv :
-send a synchronous control message to the modem
-wait for an ack or a timeout
-return the value if needed.

In order to run these synchronous usb messages we need a kernel thread.



Please comment and consider for inclusion.

The driver has been tested  with sagem fast 800 modems with different 
eagle chipset revision and with ADI 930 since April 2005.

Thanks.

Matthieu

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ueagle-atm.patch
Type: text/x-patch
Size: 53256 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/usbatm/attachments/20051029/517a7863/ueagle-atm-0001.bin
From duncan.sands at math.u-psud.fr  Mon Oct 31 03:55:43 2005
From: duncan.sands at math.u-psud.fr (Duncan Sands)
Date: Mon Oct 31 03:56:08 2005
Subject: [PATCH] info to atm layer about broken connection
In-Reply-To: <200510302244.09734.stf_xl@wp.pl>
References: <200510302015.14047.stf_xl@wp.pl>
	<200510302100.44285.duncan.sands@math.u-psud.fr>
	<200510302244.09734.stf_xl@wp.pl>
Message-ID: <200510310955.44001.duncan.sands@math.u-psud.fr>

> Hi Duncan
> > Hi Staszek, thanks for the patch, however I think this is the
> > wrong approach.  The right thing to do is to go through the list
> > of vccs and do vcc_release_async() on each one.  
> vcc_release_async() don't work with pppoatm, I don't know why,
> simply after disconnect modem, ppp demon still works 
> and ifconfig command show me connection is ok.
> Using vcc->push(vcc, NULL) kill pppd with
> Modem hangup message in logs.

that sounds like a bug in the pppoatm driver.  I will look into this.

> > Also, as far as I can see the use of try_module_get is pointless.  Why do
> > you think it is needed?
> It depends on approach, someone would like to finish connection when 
> net driver module is unloaded, other one would like to prevent unloading 
> module. I preffer second approach as is in (for example) pppoatm .
>
> Adding try_module_get and module_put pair in subdriver atm_start() and atm_stop() 
> propably block unload module anyway.

It would, which is why I don't want it.  Can you please explain why it is
useful to have the connection be gone before the module unload completes?
I don't really have anything against it, except that this kind of
synchronous unloading can easily cause rmmod to hang indefinitely (for
example: the output of rmmod is piped to a socket that goes through the
ATM device; I don't know if this is really possible, just giving you
the idea), so better to avoid it if possible.  For example, the proc
filesystem entries /proc/net/atm/speed* can also continue to exist after
the speedtch module is unloaded, or the device is removed, because it
would be much harder to do it differently.

Ciao,

Duncan.

From stf_xl at wp.pl  Mon Oct 31 06:17:23 2005
From: stf_xl at wp.pl (Stanislaw Gruszka)
Date: Mon Oct 31 05:10:31 2005
Subject: [PATCH] info to atm layer about broken connection
In-Reply-To: <200510310955.44001.duncan.sands@math.u-psud.fr>
References: <200510302015.14047.stf_xl@wp.pl> <200510302244.09734.stf_xl@wp.pl>
	<200510310955.44001.duncan.sands@math.u-psud.fr>
Message-ID: <200510311217.23942.stf_xl@wp.pl>

Hi 
> > simply after disconnect modem, ppp demon still works 
> > and ifconfig command show me connection is ok.
> > Using vcc->push(vcc, NULL) kill pppd with
> > Modem hangup message in logs.
> 
> that sounds like a bug in the pppoatm driver.  I will look into this.
I don't know, however it seems pushing NULL is ok.
I found in net/atm/pppoatm.c :

/* Called when an AAL5 PDU comes in */
static void pppoatm_push(struct atm_vcc *atmvcc, struct sk_buff *skb)
{
	struct pppoatm_vcc *pvcc = atmvcc_to_pvcc(atmvcc);
	DPRINTK("pppoatm push\n");
	if (skb == NULL) {			/* VCC was closed */
		DPRINTK("removing ATMPPP VCC %p\n", pvcc);
		pppoatm_unassign_vcc(atmvcc);
		atmvcc->push(atmvcc, NULL);	/* Pass along bad news */
		return;
	}


and in net/atm/raw.c :

/*
 * SKB == NULL indicates that the link is being closed
 */

static void atm_push_raw(struct atm_vcc *vcc,struct sk_buff *skb)
{
	if (skb) {
		struct sock *sk = sk_atm(vcc);

		skb_queue_tail(&sk->sk_receive_queue, skb);
		sk->sk_data_ready(sk, skb->len);
	}
}

>
> > > Also, as far as I can see the use of try_module_get is pointless.  Why do
> > > you think it is needed?
> > It depends on approach, someone would like to finish connection when 
> > net driver module is unloaded, other one would like to prevent unloading 
> > module. I preffer second approach as is in (for example) pppoatm .
> >
> > Adding try_module_get and module_put pair in subdriver atm_start() and atm_stop() 
> > propably block unload module anyway.
> 
> It would, which is why I don't want it.  Can you please explain why it is
> useful to have the connection be gone before the module unload completes?
Remain connection when device is gone give some problems (at least on pppoatm): 
- you can read/write to not working interface and there is no indication 
for user the link is broken
- you must reload atm module before you can establish new connection, 
even when old one was disable. 	
     
> I don't really have anything against it, except that this kind of
> synchronous unloading can easily cause rmmod to hang indefinitely (for
> example: the output of rmmod is piped to a socket that goes through the
> ATM device; I don't know if this is really possible, just giving you
> the idea), so better to avoid it if possible.  
I hope higher layers properly handle this race condition possibility.

> For example, the proc 
> filesystem entries /proc/net/atm/speed* can also continue to exist after 
> the speedtch module is unloaded, or the device is removed, because it
> would be much harder to do it differently.

Ok, but if we call read on unloaded procfs entries we get error 
(propably -ENOENT),  with internet connection there is no error,
only sleeping forever.

Summary:
 - Info to atm layer that link is broken when device is removed or module unloaded is necessary. 
 - Prevent subdriver module unloading when there is working connection is nice (lets root 
disable connection (kill pppd or atmarpd) before unload module).

__
Thanks
Staszek Gruszka


From duncan.sands at math.u-psud.fr  Mon Oct 31 05:52:51 2005
From: duncan.sands at math.u-psud.fr (Duncan Sands)
Date: Mon Oct 31 05:53:13 2005
Subject: [PATCH] info to atm layer about broken connection
In-Reply-To: <200510311217.23942.stf_xl@wp.pl>
References: <200510302015.14047.stf_xl@wp.pl>
	<200510310955.44001.duncan.sands@math.u-psud.fr>
	<200510311217.23942.stf_xl@wp.pl>
Message-ID: <200510311152.51777.duncan.sands@math.u-psud.fr>

Hi Stanislaw,

> > > simply after disconnect modem, ppp demon still works 
> > > and ifconfig command show me connection is ok.
> > > Using vcc->push(vcc, NULL) kill pppd with
> > > Modem hangup message in logs.
> > 
> > that sounds like a bug in the pppoatm driver.  I will look into this.
> I don't know, however it seems pushing NULL is ok.
> I found in net/atm/pppoatm.c :
> 
> /* Called when an AAL5 PDU comes in */
> static void pppoatm_push(struct atm_vcc *atmvcc, struct sk_buff *skb)
> {
> 	struct pppoatm_vcc *pvcc = atmvcc_to_pvcc(atmvcc);
> 	DPRINTK("pppoatm push\n");
> 	if (skb == NULL) {			/* VCC was closed */
> 		DPRINTK("removing ATMPPP VCC %p\n", pvcc);
> 		pppoatm_unassign_vcc(atmvcc);
> 		atmvcc->push(atmvcc, NULL);	/* Pass along bad news */
> 		return;
> 	}
> 
> 
> and in net/atm/raw.c :
> 
> /*
>  * SKB == NULL indicates that the link is being closed
>  */
> 
> static void atm_push_raw(struct atm_vcc *vcc,struct sk_buff *skb)
> {
> 	if (skb) {
> 		struct sock *sk = sk_atm(vcc);
> 
> 		skb_queue_tail(&sk->sk_receive_queue, skb);
> 		sk->sk_data_ready(sk, skb->len);
> 	}
> }

Here's what Chas Williams (ATM maintainer told me):

"... I believe that all
you should need to do is go through the list of vcc's that belong to your
card and call vcc_release_async().  the next time the user space process
that has control of the socket belonging to the vcc will get an error
and close the socket.  the socket release() is responsible for sending
the NULL skb to the next protocol layer."

So indeed a NULL skb should be sent, but not by the driver.  That's why
I say it looks like a bug in the ATM layer.

> > > > Also, as far as I can see the use of try_module_get is pointless.  Why do
> > > > you think it is needed?
> > > It depends on approach, someone would like to finish connection when 
> > > net driver module is unloaded, other one would like to prevent unloading 
> > > module. I preffer second approach as is in (for example) pppoatm .
> > >
> > > Adding try_module_get and module_put pair in subdriver atm_start() and atm_stop() 
> > > propably block unload module anyway.
> > 
> > It would, which is why I don't want it.  Can you please explain why it is
> > useful to have the connection be gone before the module unload completes?
> Remain connection when device is gone give some problems (at least on pppoatm): 
> - you can read/write to not working interface and there is no indication 
> for user the link is broken

This has nothing to do with module unloading.  You are explaining why you want
the connection to be shut down when the device is removed.  I agree that the
connection should be shutdown.  I guess I wasn't clear: my question was: why
is it important that the connection be completely shutdown before the rmmod
completes, rather than (maybe) soon afterwards.  This is the difference between
doing a synchronous shutdown (in which you tell the ATM layer to shutdown, and
you wait for the shutdown to complete before allowing the module unload to finish),
and an asynchronous shutdown (in which you tell the ATM layer to shutdown, but
don't wait for it to complete).

> - you must reload atm module before you can establish new connection, 
> even when old one was disable. 	

Same remark as above.

> > I don't really have anything against it, except that this kind of
> > synchronous unloading can easily cause rmmod to hang indefinitely (for
> > example: the output of rmmod is piped to a socket that goes through the
> > ATM device; I don't know if this is really possible, just giving you
> > the idea), so better to avoid it if possible.  
> I hope higher layers properly handle this race condition possibility.

It's not a race condition, and in a sense there's nothing that can be done
about it.  If A is waiting for B, but B is waiting for A, you get a deadlock,
that's all.  The trick is to make sure this never happens, by making sure that
A or B doesn't wait.  For example, if, on module unload, the driver code doesn't
wait for anything, there is no problem.  That is the case now, and I'd rather
not change it.  But it seems to me you don't really want synchronous shutdown
anyway: you just want the connection to be killed.  

> > For example, the proc 
> > filesystem entries /proc/net/atm/speed* can also continue to exist after 
> > the speedtch module is unloaded, or the device is removed, because it
> > would be much harder to do it differently.
> 
> Ok, but if we call read on unloaded procfs entries we get error 
> (propably -ENOENT),  with internet connection there is no error,
> only sleeping forever.

Sure, I agree there should be an error in the internet connection case too
(this has been on my TODO list for an awfully long time).  But I don't see
what this has to do with adding calls to try_module_get.

> Summary:
>  - Info to atm layer that link is broken when device is removed or module unloaded is necessary. 

I agree.

>  - Prevent subdriver module unloading when there is working connection is nice (lets root 
> disable connection (kill pppd or atmarpd) before unload module).

You still haven't explained why this is useful.  You've only explained why breaking
the link is a good thing.

Ciao,

D.

From stf_xl at wp.pl  Mon Oct 31 07:33:20 2005
From: stf_xl at wp.pl (Stanislaw Gruszka)
Date: Mon Oct 31 07:26:37 2005
Subject: [PATCH] info to atm layer about broken connection
In-Reply-To: <200510311152.51777.duncan.sands@math.u-psud.fr>
References: <200510302015.14047.stf_xl@wp.pl> <200510311217.23942.stf_xl@wp.pl>
	<200510311152.51777.duncan.sands@math.u-psud.fr>
Message-ID: <200510311333.20436.stf_xl@wp.pl>

Hi Duncan
> Here's what Chas Williams (ATM maintainer told me):
> 
> "... I believe that all
> you should need to do is go through the list of vcc's that belong to your
> card and call vcc_release_async().  the next time the user space process
> that has control of the socket belonging to the vcc will get an error
> and close the socket.  the socket release() is responsible for sending
> the NULL skb to the next protocol layer."
> 
> So indeed a NULL skb should be sent, but not by the driver.  That's why
> I say it looks like a bug in the ATM layer.
> 
> > > > > Also, as far as I can see the use of try_module_get is pointless.  Why do
> > > > > you think it is needed?
> > > > It depends on approach, someone would like to finish connection when 
> > > > net driver module is unloaded, other one would like to prevent unloading 
> > > > module. I preffer second approach as is in (for example) pppoatm .
> > > >
> > > > Adding try_module_get and module_put pair in subdriver atm_start() and atm_stop() 
> > > > propably block unload module anyway.
> > > 
> > > It would, which is why I don't want it.  Can you please explain why it is
> > > useful to have the connection be gone before the module unload completes?
> > Remain connection when device is gone give some problems (at least on pppoatm): 
> > - you can read/write to not working interface and there is no indication 
> > for user the link is broken
> 
> This has nothing to do with module unloading.  You are explaining why you want
> the connection to be shut down when the device is removed.  I agree that the
> connection should be shutdown.  I guess I wasn't clear: my question was: why
> is it important that the connection be completely shutdown before the rmmod
> completes, rather than (maybe) soon afterwards.  This is the difference between
> doing a synchronous shutdown (in which you tell the ATM layer to shutdown, and
> you wait for the shutdown to complete before allowing the module unload to finish),
> and an asynchronous shutdown (in which you tell the ATM layer to shutdown, but
> don't wait for it to complete).
> > - you must reload atm module before you can establish new connection, 
> > even when old one was disable. 	
> 
> Same remark as above.
> 
> > > I don't really have anything against it, except that this kind of
> > > synchronous unloading can easily cause rmmod to hang indefinitely (for
> > > example: the output of rmmod is piped to a socket that goes through the
> > > ATM device; I don't know if this is really possible, just giving you
> > > the idea), so better to avoid it if possible.  
> > I hope higher layers properly handle this race condition possibility.
> 
> It's not a race condition, and in a sense there's nothing that can be done
> about it.  If A is waiting for B, but B is waiting for A, you get a deadlock,
> that's all.  The trick is to make sure this never happens, by making sure that
> A or B doesn't wait.  For example, if, on module unload, the driver code doesn't
> wait for anything, there is no problem.  That is the case now, and I'd rather
> not change it.  But it seems to me you don't really want synchronous shutdown
> anyway: you just want the connection to be killed.  
Yes, vcc should be closed asynchronously but vcc_release_async() don't work now, 
does it ? 

AFAIK try_module_get() in usbatm_atm_open() and module_put() in usbatm_atm_close() 
prevent unload module when there is atm connection, so there shouldn't be 
any deadlock with rmmod. 

My patch send NULL skb only when modem is physically disconnect form usb port. 
I think it is good to synchronously shutdown connection in such situation. 
I review push function in pppoatm, clip and br2684 drivers, all of them expect 
to get NULL skb and it is interpreted in the same manner - link is broken.

__
Regards
Staszek Gruszka



From duncan.sands at math.u-psud.fr  Mon Oct 31 08:01:34 2005
From: duncan.sands at math.u-psud.fr (Duncan Sands)
Date: Mon Oct 31 08:01:54 2005
Subject: [PATCH] info to atm layer about broken connection
In-Reply-To: <200510311333.20436.stf_xl@wp.pl>
References: <200510302015.14047.stf_xl@wp.pl>
	<200510311152.51777.duncan.sands@math.u-psud.fr>
	<200510311333.20436.stf_xl@wp.pl>
Message-ID: <200510311401.34539.duncan.sands@math.u-psud.fr>

Hi Stanislaw,

>> ... But it seems to me you don't really want synchronous shutdown
> > anyway: you just want the connection to be killed.  
> Yes, vcc should be closed asynchronously but vcc_release_async() don't work now, 
> does it ? 

if it doesn't work then that's a reason to fix it, not to work around it.

> AFAIK try_module_get() in usbatm_atm_open() and module_put() in usbatm_atm_close() 
> prevent unload module when there is atm connection, so there shouldn't be 
> any deadlock with rmmod. 

You still haven't explained why you want to prevent the module from being unloaded.
As I said early on, I want it to be possible to unload the module at anytime.  That's
not set in stone, but in order for it to be changed you need to supply a good reason.
Right now, the module can be unloaded at any moment; the module unload disconnects
the device, so the effect of unloading is the same as unplugging the device.  I'm
guessing that the things you don't like the current module unloading behaviour are
exactly the same things that annoy you when the device is unplugged.  Is that right?

> My patch send NULL skb only when modem is physically disconnect form usb port.

It is impossible to tell the difference between a physical disconnect
and a logical disconnect (= module unload, usbfs ioctl, hotplug restart).
Your patch sends a NULL skb also when the module is unloaded for example.

> I think it is good to synchronously shutdown connection in such situation.

Why is this better than asynchronous shutdown?  Does your patch even do a
synchronous shutdown?  I don't see it waiting for the vcc's to go down.
Maybe there is some confusion here about the meaning of "synchronous
shutdown".  There are two things here: one is to put the socket in a state
in which it understands that the connection is closed.  This can be done
by the driver without doing any waiting; this is what I mean by asynchronous
shutdown.  The other thing is the actual destruction of the vcc, which
doesn't happen (as far as I know) until the userspace application closes the
socket.  So if you don't want USB device disconnection to complete before all
vccs have been destroyed, then you have to wait for the vccs to go down;
this is synchronous shutdown.  I hope it is now clear what I mean by
asynchronous vs synchronous shutdown.  Which one do you think is best,
and why?  I don't want to do synchronous shutdown unless there is an
excellent reason to do so.

> I review push function in pppoatm, clip and br2684 drivers, all of them expect 
> to get NULL skb and it is interpreted in the same manner - link is broken.

Yes, but who should send it?  Check out this thread:

http://www.atm.tut.fi/list-archive/linux-atm/msg06111.html

All the best,

Duncan.

From stf_xl at wp.pl  Mon Oct 31 09:58:11 2005
From: stf_xl at wp.pl (Stanislaw Gruszka)
Date: Mon Oct 31 09:51:30 2005
Subject: [PATCH] info to atm layer about broken connection
In-Reply-To: <200510311401.34539.duncan.sands@math.u-psud.fr>
References: <200510302015.14047.stf_xl@wp.pl> <200510311333.20436.stf_xl@wp.pl>
	<200510311401.34539.duncan.sands@math.u-psud.fr>
Message-ID: <200510311558.11821.stf_xl@wp.pl>

Hi again Duncan
> >> ... But it seems to me you don't really want synchronous shutdown
> > > anyway: you just want the connection to be killed.  
> > Yes, vcc should be closed asynchronously but vcc_release_async() don't work now, 
> > does it ? 
> 
> if it doesn't work then that's a reason to fix it, not to work around it.
ATM layer is quite complex, however it seems vcc_release_async() 
set ATM_VF_CLOSE flag but no one test it later. 

> > AFAIK try_module_get() in usbatm_atm_open() and module_put() in usbatm_atm_close() 
> > prevent unload module when there is atm connection, so there shouldn't be 
> > any deadlock with rmmod. 
> 
> You still haven't explained why you want to prevent the module from being unloaded.
> As I said early on, I want it to be possible to unload the module at anytime.  That's
> not set in stone, but in order for it to be changed you need to supply a good reason.
> Right now, the module can be unloaded at any moment; the module unload disconnects
> the device, so the effect of unloading is the same as unplugging the device.  I'm
> guessing that the things you don't like the current module unloading behaviour are
> exactly the same things that annoy you when the device is unplugged.  Is that right?
Well I rather think that try_module_get(subdriver_module) is standard behavior, 
for example atm layer prevent unload usbatm module when there exist vcc 
(functions __vcc_connect() and vcc_destroy_socket() in net/atm/common.c).
So usbatm should also prevent unload subdriver module when is needed.

> 
> > My patch send NULL skb only when modem is physically disconnect form usb port.
> 
> It is impossible to tell the difference between a physical disconnect
> and a logical disconnect (= module unload, usbfs ioctl, hotplug restart).
> Your patch sends a NULL skb also when the module is unloaded for example.
I didn't know usb_driver.disconnect can be called in usbfs or hotplug context,
I thought only when module is unloaded or device removed.
If we assume usb_driver.disconnect is called only in such situations,
using try_module_get() prevent call usbatm_usb_disconnect when
vcc list is not empty.
 
> > I think it is good to synchronously shutdown connection in such situation.
> 
> Why is this better than asynchronous shutdown?  Does your patch even do a
> synchronous shutdown?  I don't see it waiting for the vcc's to go down.
> Maybe there is some confusion here about the meaning of "synchronous
> shutdown".  There are two things here: one is to put the socket in a state
> in which it understands that the connection is closed.  This can be done
> by the driver without doing any waiting; this is what I mean by asynchronous
> shutdown.  The other thing is the actual destruction of the vcc, which
> doesn't happen (as far as I know) until the userspace application closes the
> socket.  So if you don't want USB device disconnection to complete before all
> vccs have been destroyed, then you have to wait for the vccs to go down;
> this is synchronous shutdown.  I hope it is now clear what I mean by
> asynchronous vs synchronous shutdown.  Which one do you think is best,
> and why?  I don't want to do synchronous shutdown unless there is an
> excellent reason to do so.
Ah, I simply understand that push->(vcc, NULL) is sync shutdown 
and call vcc_release_async() is async shoutdown.
 
> > I review push function in pppoatm, clip and br2684 drivers, all of them expect 
> > to get NULL skb and it is interpreted in the same manner - link is broken.
> 
> Yes, but who should send it?  Check out this thread:
> 
> http://www.atm.tut.fi/list-archive/linux-atm/msg06111.html
Conclusion of the thread is using vcc_release_async(). 

__
Regards
Staszek Gruszka

From duncan.sands at math.u-psud.fr  Mon Oct 31 10:20:12 2005
From: duncan.sands at math.u-psud.fr (Duncan Sands)
Date: Mon Oct 31 10:20:31 2005
Subject: [PATCH] info to atm layer about broken connection
In-Reply-To: <200510311558.11821.stf_xl@wp.pl>
References: <200510302015.14047.stf_xl@wp.pl>
	<200510311401.34539.duncan.sands@math.u-psud.fr>
	<200510311558.11821.stf_xl@wp.pl>
Message-ID: <200510311620.12635.duncan.sands@math.u-psud.fr>

Hi Stanislaw,

> > You still haven't explained why you want to prevent the module from being unloaded.
> > As I said early on, I want it to be possible to unload the module at anytime.  That's
> > not set in stone, but in order for it to be changed you need to supply a good reason.
> > Right now, the module can be unloaded at any moment; the module unload disconnects
> > the device, so the effect of unloading is the same as unplugging the device.  I'm
> > guessing that the things you don't like the current module unloading behaviour are
> > exactly the same things that annoy you when the device is unplugged.  Is that right?
> Well I rather think that try_module_get(subdriver_module) is standard behavior, 
> for example atm layer prevent unload usbatm module when there exist vcc 
> (functions __vcc_connect() and vcc_destroy_socket() in net/atm/common.c).
> So usbatm should also prevent unload subdriver module when is needed.

no, it is the ATM layer that should be changed.  A long time ago, in a galaxy
far far away there were no hotpluggable devices, i.e. devices which can appear
and disappear on the fly.  Then there was USB.  The ATM layer was written before
the USB layer, and does things in an out-of-date way.  It is standard for USB
drivers to be unloadable at any time - they just do a device disconnect then
unload.  After all, there is *no advantage* to not allowing module unload.  Your
argument is that: usbatm is unloadable because of ATM layer properties, thus
speedtch should be unloadable likewise.  But that is an empty argument.  I can
likewise say: USB drivers try to always be unloadable - the ATM layer should
be changed to be like USB.  Who is right?  To determine that, the question is:
is there any advantage to stopping module unload (no); is there any advantage
to allowing module unload (yes).

> > > My patch send NULL skb only when modem is physically disconnect form usb port.
> > 
> > It is impossible to tell the difference between a physical disconnect
> > and a logical disconnect (= module unload, usbfs ioctl, hotplug restart).
> > Your patch sends a NULL skb also when the module is unloaded for example.
> I didn't know usb_driver.disconnect can be called in usbfs or hotplug context,
> I thought only when module is unloaded or device removed.
> If we assume usb_driver.disconnect is called only in such situations,
> using try_module_get() prevent call usbatm_usb_disconnect when
> vcc list is not empty.

I understand what you are saying, but since the USB device can be unplugged
at a time when there are many vccs open, you have to be able to handle this
situation correctly anyway.  If you do handle it correctly, then there is no
longer any reason for disallowing module unload.

> Conclusion of the thread is using vcc_release_async(). 

Yes.  I never had the time to check how much work it would be to make
vcc_release_async work properly.  Maybe it is a hard problem.  Maybe
it is simpler to simply shove a NULL skb down.  I would like to
understand the situation perfectly before accepting any patches.

All the best,

Duncan.

From akpm at osdl.org  Mon Oct 31 18:58:03 2005
From: akpm at osdl.org (Andrew Morton)
Date: Mon Oct 31 18:58:09 2005
Subject: [PATCH]  Eagle and ADI 930 usb adsl modem driver
In-Reply-To: <4363F9B5.6010907@free.fr>
References: <4363F9B5.6010907@free.fr>
Message-ID: <20051031155803.2e94069f.akpm@osdl.org>

matthieu castet <castet.matthieu@free.fr> wrote:
>
> Hi,
> 
> attached is the driver for USB ADSL modems based on the ADI eagle
> chipset using the usb_atm infrastructure.
> 

Dunno much about USB drivers, but..

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

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

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


> ...
> +static int uea_kthread(void *data)
> +{
> +	struct uea_softc *sc = (struct uea_softc *)data;

Unneeded cast.

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


General: the patch adds tons of trailing whitespace.  I stripped that off
the patch I added to -mm.


Trivial fixups:


 drivers/usb/atm/ueagle-atm.c |   31 ++++++++++++++-----------------
 1 files changed, 14 insertions(+), 17 deletions(-)

diff -puN drivers/usb/atm/ueagle-atm.c~eagle-and-adi-930-usb-adsl-modem-driver-tidies drivers/usb/atm/ueagle-atm.c
--- 25/drivers/usb/atm/ueagle-atm.c~eagle-and-adi-930-usb-adsl-modem-driver-tidies	Mon Oct 31 15:56:36 2005
+++ 25-akpm/drivers/usb/atm/ueagle-atm.c	Mon Oct 31 15:56:36 2005
@@ -74,17 +74,17 @@ static int uea_read_proc(char *page, cha
 
 static struct usb_driver uea_driver;
 static struct proc_dir_entry *uea_procdir;
-DECLARE_MUTEX(uea_semaphore);
+static DECLARE_MUTEX(uea_semaphore);
 static const char *chip_name[] = {"ADI930", "Eagle I", "Eagle II", "Eagle III"};
 
 /*
  * User supplied debug level
  */
-static unsigned int debug = 0;
+static unsigned int debug;
 
-static int modem_index = 0;
-static int sync_wait[NB_MODEM] = {[0 ... (NB_MODEM - 1)] = 0 };
-static char *cmv_file[NB_MODEM] = {[0 ... (NB_MODEM - 1)] = NULL };
+static int modem_index;
+static int sync_wait[NB_MODEM];
+static char *cmv_file[NB_MODEM];
 
 module_param(debug, uint, 0644);
 MODULE_PARM_DESC(debug, "module debug level (0=off,1=on,2=verbose)");
@@ -314,15 +314,13 @@ static int uea_idma_write(struct uea_sof
 
 	memcpy(xfer_buff, data, size);
 
-	ret =
-	    usb_bulk_msg(sc->usb_dev,
+	ret = usb_bulk_msg(sc->usb_dev,
 			 usb_sndbulkpipe(sc->usb_dev, UEA_IDMA_PIPE),
 			 xfer_buff, size, &bytes_read, BULK_TIMEOUT);
 
 	kfree(xfer_buff);
-	if (ret < 0) {
+	if (ret < 0)
 		return ret;
-	}
 	if (size != bytes_read) {
 		uea_err(INS_TO_USBDEV(sc), "size != bytes_read %d %d\n", size,
 		       bytes_read);
@@ -873,7 +871,7 @@ out:
 
 static int uea_kthread(void *data)
 {
-	struct uea_softc *sc = (struct uea_softc *)data;
+	struct uea_softc *sc = data;
 	int ret = -EAGAIN;
 
 	uea_enters(INS_TO_USBDEV(sc));
@@ -1135,7 +1133,7 @@ static void uea_stop(struct uea_softc *s
 	/* stop any pending boot process */
 	flush_scheduled_work();
 
-     	uea_request(sc, UEA_SET_MODE, UEA_LOOPBACK_ON, 0, NULL);
+	uea_request(sc, UEA_SET_MODE, UEA_LOOPBACK_ON, 0, NULL);
 
 	usb_kill_urb(sc->urb_int);
 	kfree(sc->urb_int->transfer_buffer);
@@ -1146,7 +1144,6 @@ static void uea_stop(struct uea_softc *s
 	uea_leaves(INS_TO_USBDEV(sc));
 }
 
-
 /* syfs interface */
 static struct uea_softc *dev_to_uea(struct device *dev)
 {
@@ -1161,7 +1158,7 @@ static struct uea_softc *dev_to_uea(stru
 	if (!usbatm)
 		return NULL;
 
-	return (struct uea_softc *)usbatm->driver_data;
+	return usbatm->driver_data;
 }
 
 /* we need to use semaphore until sysfs and removable devices is fixed
@@ -1247,14 +1244,14 @@ static int uea_getesi(struct uea_softc *
 /* ATM stuff */
 static int uea_atm_open(struct usbatm_data *usbatm, struct atm_dev *atm_dev)
 {
-	struct uea_softc *sc = (struct uea_softc *)usbatm->driver_data;
+	struct uea_softc *sc = usbatm->driver_data;
 
 	return uea_getesi(sc, atm_dev->esi);
 }
 
 static int uea_heavy(struct usbatm_data *usbatm, struct usb_interface *intf)
 {
-	struct uea_softc *sc = (struct uea_softc *)usbatm->driver_data;
+	struct uea_softc *sc = usbatm->driver_data;
 
 	wait_event(sc->sync_q, IS_OPERATIONAL(sc));
 
@@ -1340,7 +1337,7 @@ static int uea_bind(struct usbatm_data *
 			return ret;
 	}
 
-	sc = kcalloc(1, sizeof(struct uea_softc), GFP_KERNEL);
+	sc = kzalloc(sizeof(struct uea_softc), GFP_KERNEL);
 	if (!sc) {
 		uea_err(INS_TO_USBDEV(sc), "uea_init: not enough memory !\n");
 		return -ENOMEM;
@@ -1382,7 +1379,7 @@ static void destroy_fs_entries(struct ue
 
 static void uea_unbind(struct usbatm_data *usbatm, struct usb_interface *intf)
 {
-	struct uea_softc *sc = (struct uea_softc *)usbatm->driver_data;
+	struct uea_softc *sc = usbatm->driver_data;
 
 	destroy_fs_entries(sc, intf);
 	uea_stop(sc);
_


