Re: Question r/e zero byte bulk transfer on musb gadget (causes kernel panic)
On 01/11/2014 15:05, Alan Stern wrote: On Sat, 1 Nov 2014, Breton M. Saunders wrote: This is required behavior, for example, during the data phase of a bulk-only mass-storage transfer. The specification states that under certain circumstances, the device _must_ send a zero-length packet on its bulk-IN endpoint. Hi Alan - thanks for that. Can I ask: have you got a reference for that? It will help when I arrive back in the office on Monday. I've briefly skimmed the usb mass storage bulk only document (from 1999) and am looking at usb-msc-0.2.pdf now; but am not finding details on zero-length transfers on bulk. So on careful investigation, it turns out I misspoke. In the 1.0 revision of the Bulk-Only Transport specification (the filename is probably something like usbmassbulk_10.pdf), the discussion of case 4 in section 6.7.2 says: If the device actually transfers less data than the host indicated, then: The device may end the transfer with a short packet. The device shall STALL the Bulk-In pipe. Thus, if the device chooses to end the transfer with a short packet, the packet may need to have length 0 (for case 4). But the device isn't required to do this, whereas it _is_ required to STALL the bulk-IN pipe. Ironically, many devices in the real world _do_ send a short packet and _don't_ send a STALL. Regardless, the principle is clear: Devices _should_ be able to send 0-length packets on bulk endpoints. See the discussion of short packets in sections 5.3.2 and 5.8.3 of the USB-2.0 spec. Hi Alan, Thanks again for your help. I think my understanding of the bulk transfer protocol was incorrectly confused with my previous work on control transfers. It looks like there is no concept of transfer vs transaction in bulk like there is in control. In bulk, the state machine consists of a single token-data-handshake transition - the only way a write system call is terminated is by writing a short packet. Therefore, a short packet being 0 bytes is perfectly legitimate - and therefore, performing a write from userland of zero bytes should also be permitted. I reckon its off I go debugging MUSB. (Note: I'm stuck using 2.6.37; so the bug I've encountered may not be occurring on newer kernels). Cheers, -Brett -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Question r/e zero byte bulk transfer on musb gadget (causes kernel panic)
On Mon, 3 Nov 2014, Breton M. Saunders wrote: Hi Alan, Thanks again for your help. I think my understanding of the bulk transfer protocol was incorrectly confused with my previous work on control transfers. It looks like there is no concept of transfer vs transaction in bulk like there is in control. There _is_ a concept of bulk transfers, but it exists only at a higher level of abstraction, whereas control transfers are represented directly within the USB bus protocol. In bulk, the state machine consists of a single token-data-handshake transition - the only way a write system call is terminated is by writing a short packet. I'm not entirely sure what you mean here, but you seem to have the right basic idea. A host and a device agree (somehow) on how long a bulk transfer ought to be, and if the transfer needs to be shorter than the agreed-on length then it must be terminated by a short packet. Which will have to be a zero-length packet in the case where the actual length is a multiple of the maxpacket size. Therefore, a short packet being 0 bytes is perfectly legitimate - and therefore, performing a write from userland of zero bytes should also be permitted. Yes. I reckon its off I go debugging MUSB. (Note: I'm stuck using 2.6.37; so the bug I've encountered may not be occurring on newer kernels). Good luck. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Question r/e zero byte bulk transfer on musb gadget (causes kernel panic)
On 31/10/14 14:23, Alan Stern wrote: On Fri, 31 Oct 2014, Peter Stuge wrote: Breton M. Saunders wrote: Are zero length transfers from a device to the PC on a bulk endpoint sensible? I don't see how they could be. If the device has no data to send it responds with a NAK handshake. If the device has data to send it responds with the data. But what if the host expects to receive data and the device has no data to send? In that case the device must send a zero-length packet. Otherwise the host will hang, waiting for data that the device will never send. This is required behavior, for example, during the data phase of a bulk-only mass-storage transfer. The specification states that under certain circumstances, the device _must_ send a zero-length packet on its bulk-IN endpoint. Hi Alan - thanks for that. Can I ask: have you got a reference for that? It will help when I arrive back in the office on Monday. I've briefly skimmed the usb mass storage bulk only document (from 1999) and am looking at usb-msc-0.2.pdf now; but am not finding details on zero-length transfers on bulk. I admit to being unfamiliar with usb mass storage; my work has primarily been on HID and custom bulk protocols. I was coming at this from the user side of the problem where what I was (incorrectly) doing was: write(fd, buffer, 0); where buffer is a valid virtual address, and fd is an open file descriptor on a bulk-in endpoint. If I read man 2 write (ubuntu 14.04) I find that the return code for write is undefined for a non-regular file _and_ a count value of zero. At present I've seen fit to just return -EIO (from gadgetfs) on writes of zero bytes to a non-control endpoint - however, I'm still trying to ascertain whether this behavior is correct or not. A document stating that zero length bulk transfers could allow me to get permission to investigate the problem further down the chain - into musb. Cheers, -Brett Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Question r/e zero byte bulk transfer on musb gadget (causes kernel panic)
On Sat, 1 Nov 2014, Breton M. Saunders wrote: This is required behavior, for example, during the data phase of a bulk-only mass-storage transfer. The specification states that under certain circumstances, the device _must_ send a zero-length packet on its bulk-IN endpoint. Hi Alan - thanks for that. Can I ask: have you got a reference for that? It will help when I arrive back in the office on Monday. I've briefly skimmed the usb mass storage bulk only document (from 1999) and am looking at usb-msc-0.2.pdf now; but am not finding details on zero-length transfers on bulk. So on careful investigation, it turns out I misspoke. In the 1.0 revision of the Bulk-Only Transport specification (the filename is probably something like usbmassbulk_10.pdf), the discussion of case 4 in section 6.7.2 says: If the device actually transfers less data than the host indicated, then: The device may end the transfer with a short packet. The device shall STALL the Bulk-In pipe. Thus, if the device chooses to end the transfer with a short packet, the packet may need to have length 0 (for case 4). But the device isn't required to do this, whereas it _is_ required to STALL the bulk-IN pipe. Ironically, many devices in the real world _do_ send a short packet and _don't_ send a STALL. Regardless, the principle is clear: Devices _should_ be able to send 0-length packets on bulk endpoints. See the discussion of short packets in sections 5.3.2 and 5.8.3 of the USB-2.0 spec. I admit to being unfamiliar with usb mass storage; my work has primarily been on HID and custom bulk protocols. I was coming at this from the user side of the problem where what I was (incorrectly) doing was: write(fd, buffer, 0); where buffer is a valid virtual address, and fd is an open file descriptor on a bulk-in endpoint. If I read man 2 write (ubuntu 14.04) I find that the return code for write is undefined for a non-regular file _and_ a count value of zero. At present I've seen fit to just return -EIO (from gadgetfs) on writes of zero bytes to a non-control endpoint - however, I'm still trying to ascertain whether this behavior is correct or not. gadgetfs is a whole separate story. Nevertheless, I'm pretty sure that it's supposed to return 0 for such a write, unless something goes wrong. A document stating that zero length bulk transfers could allow me to get permission to investigate the problem further down the chain - into musb. If there is a problem, it undoubtedly lies in the musb driver. There has been a fair amount of discussion on the mailing list recently about about how that driver should handle 0-length packets (although the discussion was concerned with control transfers, not bulk). Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Question r/e zero byte bulk transfer on musb gadget (causes kernel panic)
On Fri, 31 Oct 2014, Peter Stuge wrote: Breton M. Saunders wrote: Are zero length transfers from a device to the PC on a bulk endpoint sensible? I don't see how they could be. If the device has no data to send it responds with a NAK handshake. If the device has data to send it responds with the data. But what if the host expects to receive data and the device has no data to send? In that case the device must send a zero-length packet. Otherwise the host will hang, waiting for data that the device will never send. This is required behavior, for example, during the data phase of a bulk-only mass-storage transfer. The specification states that under certain circumstances, the device _must_ send a zero-length packet on its bulk-IN endpoint. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Question r/e zero byte bulk transfer on musb gadget (causes kernel panic)
Hi All, I want to ask what the correct USB behavior should be for a gadget attempting to perform a zero byte transfer (note transfer, not transaction) on a bulk-in endpoint should be: Background: * Basically I've got a hacked up kernel; hardware is TI omap dm3730 (an overo gumstix board). * I use gadget fs (for which I've done major work to fix both gadgetfs and musb). * I connect the overo board to a windows/linux/osx pc via its OTG port. I discovered that by writing a zero length packet to a bulk in endpoint I can cause a kernel panic in musb - basically I think it is trying to setup a DMA transaction with a valid pointer of zero bytes and blowing up. I encountered this by writing a crappy user-land program (by accident). Now I don't believe I should be able to panic the kernel from my stupid user program; so I could easily short-cut this so that gadgetfs disallows zero byte writes. I could also pursue this lower so that musb does not allow 0 length transactions - however, my question is more basic than that: Are zero length transfers from a device to the PC on a bulk endpoint sensible? I can see a case where a zero length transfer would cause a read thread in the host to be interrupted. Does musb/gadgetfs need to correctly support zero byte transfers, or is this a non-sensible suggestion? Cheers, -Brett -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Question r/e zero byte bulk transfer on musb gadget (causes kernel panic)
Breton M. Saunders wrote: Are zero length transfers from a device to the PC on a bulk endpoint sensible? I don't see how they could be. If the device has no data to send it responds with a NAK handshake. If the device has data to send it responds with the data. //Peter -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
