RE: [linux-usb-devel] question about mass storage gadget
-Original Message- From: Alan Stern [mailto:[EMAIL PROTECTED] Sent: Thursday, July 14, 2005 10:01 PM To: Li Yang-r58472 Cc: linux-usb-devel@lists.sourceforge.net Subject: RE: [linux-usb-devel] question about mass storage gadget On Thu, 14 Jul 2005, Li Yang-r58472 wrote: Ok. Let's change the situation to that client reply shorter DATA than host CBW requested. There will be a stall and CSW. Yes, that happens normally. At this time, the bulk-in ep is halted, there is a CSW request queued in the bulk-in ep, and clear_feature can't be executed as the queue is not empty. They form a dead-lock, and stop working. You're a little confused. Above you mentioned that set_halt fails if the queue is non-empty, which is correct. Here you state that clear_halt fails if the queue is non-empty, and that's wrong. I think it's reasonable to check the queue doing set_halt while ignore it when clear_halt. However, looking into set_halt function in omap udc driver, it returns -EAGAIN when the queue is not empty for both set_halt/clear_halt operations. It should have been tested, which makes me really confused. You're still mixed up. The gadget driver does call the set_halt function, but it doesn't call clear_halt. The Clear-Halt message is sent by the host and handled directly by the controller driver. The gadget driver isn't involved. Seems I didn't state the problem clearly. I agree that there is no problem with the mass-storage gadget driver. But the problem becomes how to deal with host's clear_feature request in device controller driver. Do we need to check the queue in udc when doing set_halt() for value equals either 0 or 1 as in omap_udc? How did we do to avoid such a situation? Or to break it? You might ask more generally: What happens if the gadget driver tries to halt the bulk-in endpoint when there is data in the queue and the host isn't reading it? Answer: The gadget will hang until the host issues either a class-specific reset or a USB port reset. Yes, that's the phenomenon I got when the clear_halt hangs. Host keep resetting once for a while. What clear_halt are you talking about? The only calls to clear_halt in file_storage.c occur in the handle_exceptions routine, which calls usb_ep_fifo_flush first. So the queues will be empty when clear_halt is called. Alan Stern --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
RE: [linux-usb-devel] question about mass storage gadget
On Fri, 15 Jul 2005, Li Yang-r58472 wrote: Seems I didn't state the problem clearly. I agree that there is no problem with the mass-storage gadget driver. But the problem becomes how to deal with host's clear_feature request in device controller driver. Do we need to check the queue in udc when doing set_halt() for value equals either 0 or 1 as in omap_udc? That must depend on the hardware capabilities of the OMAP's udc controller, concerning which I know nothing. However the driver does need to be able to clear the halt feature for bulk-in endpoints when data is already queued. Exactly how it does this is hardware-dependent. If that isn't feasible then the Gadget API needs an addition, some way for drivers to wait until the host has cleared an endpoint's halt. Alan Stern --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
RE: [linux-usb-devel] question about mass storage gadget
-Original Message- From: Alan Stern [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 13, 2005 10:21 PM To: Li Yang-r58472 Cc: linux-usb-devel@lists.sourceforge.net Subject: Re: [linux-usb-devel] question about mass storage gadget On Wed, 13 Jul 2005, Li Yang-r58472 wrote: Hi, While I was working on a device controller driver tested with mass storage, I got a question regarding on the stall condition. For mass storage device, the driver stalls the bulk-in ep when there is an error processing CBW. Then the host will send clear_feature to clear the halt condition. However set_halt in all udc drivers always checks if the IN ep queue is empty, and returns -EAGAIN when the ep queue is not empty. Here comes the problem: A problem with CBW is found. Device stalls bulk-in ep. Host sends clear_feature control transfer. Gadget layer queues error CSW to the bulk-in ep. That can't happen. The driver doesn't queue a CSW if it hasn't received a valid CBW. Ok. Let's change the situation to that client reply shorter DATA than host CBW requested. There will be a stall and CSW. At this time, the bulk-in ep is halted, there is a CSW request queued in the bulk-in ep, and clear_feature can't be executed as the queue is not empty. They form a dead-lock, and stop working. You're a little confused. Above you mentioned that set_halt fails if the queue is non-empty, which is correct. Here you state that clear_halt fails if the queue is non-empty, and that's wrong. I think it's reasonable to check the queue doing set_halt while ignore it when clear_halt. However, looking into set_halt function in omap udc driver, it returns -EAGAIN when the queue is not empty for both set_halt/clear_halt operations. It should have been tested, which makes me really confused. How did we do to avoid such a situation? Or to break it? You might ask more generally: What happens if the gadget driver tries to halt the bulk-in endpoint when there is data in the queue and the host isn't reading it? Answer: The gadget will hang until the host issues either a class-specific reset or a USB port reset. Yes, that's the phenomenon I got when the clear_halt hangs. Host keep resetting once for a while. Alan Stern --- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
RE: [linux-usb-devel] question about mass storage gadget
On Thu, 14 Jul 2005, Li Yang-r58472 wrote: Ok. Let's change the situation to that client reply shorter DATA than host CBW requested. There will be a stall and CSW. Yes, that happens normally. At this time, the bulk-in ep is halted, there is a CSW request queued in the bulk-in ep, and clear_feature can't be executed as the queue is not empty. They form a dead-lock, and stop working. You're a little confused. Above you mentioned that set_halt fails if the queue is non-empty, which is correct. Here you state that clear_halt fails if the queue is non-empty, and that's wrong. I think it's reasonable to check the queue doing set_halt while ignore it when clear_halt. However, looking into set_halt function in omap udc driver, it returns -EAGAIN when the queue is not empty for both set_halt/clear_halt operations. It should have been tested, which makes me really confused. You're still mixed up. The gadget driver does call the set_halt function, but it doesn't call clear_halt. The Clear-Halt message is sent by the host and handled directly by the controller driver. The gadget driver isn't involved. How did we do to avoid such a situation? Or to break it? You might ask more generally: What happens if the gadget driver tries to halt the bulk-in endpoint when there is data in the queue and the host isn't reading it? Answer: The gadget will hang until the host issues either a class-specific reset or a USB port reset. Yes, that's the phenomenon I got when the clear_halt hangs. Host keep resetting once for a while. What clear_halt are you talking about? The only calls to clear_halt in file_storage.c occur in the handle_exceptions routine, which calls usb_ep_fifo_flush first. So the queues will be empty when clear_halt is called. Alan Stern --- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
