Re: [linux-usb-devel] Re: Comments/questions about the Gadget API
Alan Stern wrote: Again, seems like NAK is the answer. And the way to make the gadget stop NAKing is to provide some data for it to deliver to the host: submit a request to that IN endpoint, with its data buffer. If a STALL is the right response, then halt the endpoint. Otherwise the only non-error responses are to NAK, or to provide the requested DATA. What if STALL is only temporarily the right response? That is, the gadget doesn't have any more data to send until the host gives it another command. If the host tries to read more data, it should receive a STALL. So far as I understand, that's not part of the USB device model. What happens if the host has sent all the data the gadget driver wants, and is still sending more, has filled the FIFO, and is continuing to send data? It will wait while the gadget NAKs. But the gadget driver won't know what's going on and hence won't be able to HALT the endpoint, thereby telling the host that the gadget won't accept any more. If the host is sending more data, and the gadget driver doesn't expect it, that's clearly a protocol error. (While it's true that STALL generally means there's an error, that's not the only kind of error...) Probably the only answer to these problems will be to let the host timeout the transfer. Yes. In fact, having a FIFO there doesn't affect that answer at all. In both cases (IN, OUT), this is a host side protocol error, with the only real fix being to get rid of that host side bug. - Dave --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: Comments/questions about the Gadget API
Halt endpoints by doing a wrong direction I/O ... read from an IN endpoint (instead of writing to the host), or write to an OUT endpoint (instead of reading what it wrote). This idiom avoids use of ioctls, and makes use of a code path that would otherwise just return an error. That is worse than an ioctl. No. Read and write should transfer data, not change status of an io channel. Sounds like a valid thing for a special purpose fs to do (is simple, and can be done in any language, and doesn't require special thunking ioctl layer.) That depends on whether you want to design a clean API, or you are driven by avoiding ioctl, which is a valid part of the Unix API, at all cost and your overriding concern are shell scripts. You are treating write like ioctl. Using the syscall actually designed for this is the clean solution. Write writes data, that's what it is meant for. Regards Oliver --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: Comments/questions about the Gadget API
Oliver Neukum wrote: Think of it instead as portability. The main barrier to being able to use this should be knowing USB -- not whether your chosen programming environment supports POSIX-specific APIs. Remember that _today_ you can write fully realistic user mode gadget drivers in C, C++, Python, Java, and other languages (including BASH!). Not all of those have, or want, ioctl(). Firstly, you are unlikely to see gadgetfs ported to anything that doesn't have ioctl. Reread the above. It's _already_ usable in several such programming environments. Didn't need porting. - Dave --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: Comments/questions about the Gadget API
Am Donnerstag, 7. August 2003 21:37 schrieb David Brownell: Oliver Neukum wrote: Halt endpoints by doing a wrong direction I/O ... read from an IN endpoint (instead of writing to the host), or write to an OUT endpoint (instead of reading what it wrote). ... That depends on whether you want to design a clean API, or you are driven by avoiding ioctl, which is a valid part of the Unix API, at all cost and your overriding concern are shell scripts. Think of it instead as portability. The main barrier to being able to use this should be knowing USB -- not whether your chosen programming environment supports POSIX-specific APIs. Remember that _today_ you can write fully realistic user mode gadget drivers in C, C++, Python, Java, and other languages (including BASH!). Not all of those have, or want, ioctl(). Firstly, you are unlikely to see gadgetfs ported to anything that doesn't have ioctl. Secondly, remembering to write/read in the wrong direction to halt an endpoint requires as much knowledge not about USB than an ioctl. In fact a little more as you have to know about data direction which is immaterial to halting as such. Thirdly and most importantly, kernel code shall be designed independently of user space language. It is designed to meet SuS and more importantely, the spirit of Unix, in which the io primitives have clear meaning. Read write do the obvious things their names suggest. And for manipulation of io devices as such, not involving data transfers, there is ioctl. Read write are not supposed to have side effects as the only effect. Such effects are supposed to be only secondary effects of processing data read or written, like a device becoming busy. A portable API is an API that uses POSIX like it is intended to be used. Not abusing ioctl to do things that read or write should do, but neither pushing the semantics of ioctl onto read and write. What do you do if the next special operation needs to be accomodated? Kernel interfaces are supposed to follow Unix, not some language's castrated oppinion of how io shall be performed. If you want more portability write a shared library to make available a function like gadget_halt_endpoint(). But that doesn't change the need of having a cleanly designed kernel interface. Sorry for being so long Oliver --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: Comments/questions about the Gadget API
On Wed, Aug 06, 2003 at 10:48:22PM +0200, Oliver Neukum wrote: Am Mittwoch, 6. August 2003 22:09 schrieb David Brownell: Alan Stern wrote: David: A few things have come while planning my gadget driver. The gadgetfs API still looks a bit preliminary. Judging by the source, there doesn't even appear to be any way to halt an endpoint! Anyway, I decided not to use it; the performance penalties would make it a bad model for this purpose in any case. Halt endpoints by doing a wrong direction I/O ... read from an IN endpoint (instead of writing to the host), or write to an OUT endpoint (instead of reading what it wrote). This idiom avoids use of ioctls, and makes use of a code path that would otherwise just return an error. That is worse than an ioctl. No. Read and write should transfer data, not change status of an io channel. Sounds like a valid thing for a special purpose fs to do (is simple, and can be done in any language, and doesn't require special thunking ioctl layer.) thanks, greg k-h --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: Comments/questions about the Gadget API
Alan Stern wrote: David: A few things have come while planning my gadget driver. The gadgetfs API still looks a bit preliminary. Judging by the source, there doesn't even appear to be any way to halt an endpoint! Anyway, I decided not to use it; the performance penalties would make it a bad model for this purpose in any case. Halt endpoints by doing a wrong direction I/O ... read from an IN endpoint (instead of writing to the host), or write to an OUT endpoint (instead of reading what it wrote). This idiom avoids use of ioctls, and makes use of a code path that would otherwise just return an error. It's a bit preliminary mostly in the sense that it's not been widely used yet, and I want to change how SET_CONFIGURATION gets handled (as I mentioned). But otherwise it's behaved well enough, except for some of the 2.4 hacks. Yes, I tend to think that userspace isn't the right place for a mass storage gadget driver to live. Even things like automounting usually limit the userspace hooks to directory lookups, instead of bulk i/o. On the other hand there's a lot to be said for drivers that won't oops because they aren't in the kernel ... :) The kerneldoc for usb_ep_set_halt() says that the endpoint will remain halted until the host clears it. Is that really true, the gadget driver can't clear the HALT feature? The kerneldoc says that usb_ep_clear_halt() should be used when changing altsettings; if it works then, why doesn't it work at other times? This could use clarification. Basically it does remain halted until the host clears it ... changing altsettings is done only at host request! :) But yes, that's worth some clarifying. The main trouble spot today is that some hardware (pxa2xx_udc for example) doesn't support it in any case (and can't use altsettings). usb_ep_queue() says it will return an error if the endpoint is halted. This isn't acceptable; we have to be able to queue bulk-in data on a halted endpoint, at the very least You'll be glad to know that's not correct ... none of the drivers even check, since they don't (can't) know if the endpoint is halted. Doc fix is needed. A related issue has to do with setting the HALT feature when the host tries to read/write too much. The premature end of a bulk-in transfer can be indicated by a short or zero-length packet. But you recommend avoiding ZLPs, and if the total transfer length is divisible by the packet size then there won't be a short packet. The correct thing to do is to halt the endpoint when the slave receives an excess IN PID. But we don't want The device will be NAKing in such cases, when the host asks for a packet and there's no data. Avoiding ZLPs is mostly a practical matter for protocols, since not all hardware handles them ... if you're working with hardware that handles them, and with a device protocol where the host will read them, by all means write a ZLP to the host. It ought to work just fine. Sending an automagic STALL response to the host would be wrong; the controller driver can't even know if an IN is excess or just early (before the gadget driver had quite finished preparing the data). Example: if the host writes READ_10, the gadget driver will read that and start processing it. The host will usually try to read the data bytes next, but the gadget might not be able to write any until a disk delivers the data. It would be incorrect to STALL ... but it's very correct to NAK. to halt if there is no excess IN request, because in that case the host shouldn't have to clear the halt. That means there has to be a way to set the state of a bulk endpoint so that it responds to the host by halting but otherwise remains running, a conditionally halted state. And of course, the gadget needs to be able to take the endpoint out of this state back to its normal running state. Again, seems like NAK is the answer. And the way to make the gadget stop NAKing is to provide some data for it to deliver to the host: submit a request to that IN endpoint, with its data buffer. If a STALL is the right response, then halt the endpoint. Otherwise the only non-error responses are to NAK, or to provide the requested DATA. Similar reasoning applies to OUT transfers. We don't want the controller to ACK (and store in its FIFO) excess data that the gadget can't accept; we want it to stall. In fact, to avoid races it would be good to add an extra flag bit to struct usb_request, saying that as soon as the request finishes normally the endpoint should be placed in this conditional-halt state. (For bulk-in requests such a flag isn't necessary because we aren't racing the hardware, but it would be nice to have.) This case is a lot harder. The symmetrical answer is that the device NAKs the OUT transfer (or, at high speed, the PING) until you issue a read ... but it seems like the people designing hardware don't often support that flow control model. (Likely because it increases latencies, and isn't actually necessary.) So
Re: [linux-usb-devel] Re: Comments/questions about the Gadget API
Am Mittwoch, 6. August 2003 22:09 schrieb David Brownell: Alan Stern wrote: David: A few things have come while planning my gadget driver. The gadgetfs API still looks a bit preliminary. Judging by the source, there doesn't even appear to be any way to halt an endpoint! Anyway, I decided not to use it; the performance penalties would make it a bad model for this purpose in any case. Halt endpoints by doing a wrong direction I/O ... read from an IN endpoint (instead of writing to the host), or write to an OUT endpoint (instead of reading what it wrote). This idiom avoids use of ioctls, and makes use of a code path that would otherwise just return an error. That is worse than an ioctl. Read and write should transfer data, not change status of an io channel. Regards Oliver --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: Comments/questions about the Gadget API
Oliver Neukum wrote: Halt endpoints by doing a wrong direction I/O ... read from an IN endpoint (instead of writing to the host), or write to an OUT endpoint (instead of reading what it wrote). ... That depends on whether you want to design a clean API, or you are driven by avoiding ioctl, which is a valid part of the Unix API, at all cost and your overriding concern are shell scripts. Think of it instead as portability. The main barrier to being able to use this should be knowing USB -- not whether your chosen programming environment supports POSIX-specific APIs. Remember that _today_ you can write fully realistic user mode gadget drivers in C, C++, Python, Java, and other languages (including BASH!). Not all of those have, or want, ioctl(). - Dave --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: Comments/questions about the Gadget API
Greg KH wrote: On Wed, Aug 06, 2003 at 10:48:22PM +0200, Oliver Neukum wrote: Am Mittwoch, 6. August 2003 22:09 schrieb David Brownell: Halt endpoints by doing a wrong direction I/O ... read from an IN endpoint (instead of writing to the host), or write to an OUT endpoint (instead of reading what it wrote). This idiom avoids use of ioctls, and makes use of a code path that would otherwise just return an error. That is worse than an ioctl. No. Read and write should transfer data, not change status of an io channel. Sounds like a valid thing for a special purpose fs to do (is simple, and can be done in any language, and doesn't require special thunking ioctl layer.) That was exactly my thought: simple, works from any language, no-ioctls. Though I think the priority went the other way around; simple doesn't trump the other factors. And why would you think that reading or writing wouldn't change the state of an i/o channel? :) - Dave --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: Comments/questions about the Gadget API
I'm not sure if it's worth discussing this any farther, since the controller hardware probably won't support it, but ... On Wed, 6 Aug 2003, David Brownell wrote: Alan Stern wrote: A related issue has to do with setting the HALT feature when the host tries to read/write too much. The premature end of a bulk-in transfer can be indicated by a short or zero-length packet. But you recommend avoiding ZLPs, and if the total transfer length is divisible by the packet size then there won't be a short packet. The correct thing to do is to halt the endpoint when the slave receives an excess IN PID. But we don't want The device will be NAKing in such cases, when the host asks for a packet and there's no data. Avoiding ZLPs is mostly a practical matter for protocols, since not all hardware handles them ... if you're working with hardware that handles them, and with a device protocol where the host will read them, by all means write a ZLP to the host. It ought to work just fine. Sending an automagic STALL response to the host would be wrong; the controller driver can't even know if an IN is excess or just early (before the gadget driver had quite finished preparing the data). Example: if the host writes READ_10, the gadget driver will read that and start processing it. The host will usually try to read the data bytes next, but the gadget might not be able to write any until a disk delivers the data. It would be incorrect to STALL ... but it's very correct to NAK. The controller can know when to STALL if the gadget driver tells it, by setting a bit flag in the usb_request, meaning: HALT the endpoint if the host tries to read/write any more once this request is finished. However, for my purposes a ZLP will probably do as well. to halt if there is no excess IN request, because in that case the host shouldn't have to clear the halt. That means there has to be a way to set the state of a bulk endpoint so that it responds to the host by halting but otherwise remains running, a conditionally halted state. And of course, the gadget needs to be able to take the endpoint out of this state back to its normal running state. Again, seems like NAK is the answer. And the way to make the gadget stop NAKing is to provide some data for it to deliver to the host: submit a request to that IN endpoint, with its data buffer. If a STALL is the right response, then halt the endpoint. Otherwise the only non-error responses are to NAK, or to provide the requested DATA. What if STALL is only temporarily the right response? That is, the gadget doesn't have any more data to send until the host gives it another command. If the host tries to read more data, it should receive a STALL. If it doesn't but sends a new command, then more data will be available so a STALL is inappropriate -- and the host shouldn't have to clear one if it didn't try to read any excess. Similar reasoning applies to OUT transfers. We don't want the controller to ACK (and store in its FIFO) excess data that the gadget can't accept; we want it to stall. In fact, to avoid races it would be good to add an extra flag bit to struct usb_request, saying that as soon as the request finishes normally the endpoint should be placed in this conditional-halt state. (For bulk-in requests such a flag isn't necessary because we aren't racing the hardware, but it would be nice to have.) This case is a lot harder. The symmetrical answer is that the device NAKs the OUT transfer (or, at high speed, the PING) until you issue a read ... but it seems like the people designing hardware don't often support that flow control model. (Likely because it increases latencies, and isn't actually necessary.) So hardware is usually set up to accept OUT data whenever the endpoint is enabled and its FIFO has space. So if the host managed to find time to get the data to that streaming endpoint, it'll be there when your gadget driver finds time to process it. When you're writing a gadget driver this should all be transparent unless the device protocol is mis-designed. But you'll need to know that for both IN and OUT transfers, data might still sit in endpoint FIFOs after your write (or read, respectively) transfer complete() callback. Lots of driver frameworks act in that same way. What happens if the host has sent all the data the gadget driver wants, and is still sending more, has filled the FIFO, and is continuing to send data? It will wait while the gadget NAKs. But the gadget driver won't know what's going on and hence won't be able to HALT the endpoint, thereby telling the host that the gadget won't accept any more. Probably the only answer to these problems will be to let the host timeout the transfer. Alan Stern --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce,
