On Mon, 5 Aug 2013, Sarah Sharp wrote: > > > You are completely right, no current HCD writes more than a 15 byte BOS descriptor. > > > However, if a future HCD were to attempt to write a descriptor longer than 15 bytes, > > > the value of wLength would be larger than the space available in tbuf, > > > and an overflow would occur. > > > > True. At that future time, tbuf would have to be expanded. > > Hi Alan, > > I was the one that suggested Sean send this patch, and is a part of a > new HCD. Sean works for a team within Intel that is working on a new > "media agnostic" host controller that talks to devices that have a USB > interface, but aren't necessarily hanging off a USB bus. For example, > the device may actually be a PCI device, but we want it to show up to > the USB core as a standard USB device. Sending something equivalent to USB packets over a PCI bus? Weird. > The architecture isn't set in stone yet, and we're not sure if the host > driver will need to return a BOS descriptor bigger than 15 bytes. > However, it does seem useful to future-proof this particular part of the > USB core for when we add bigger BOS descriptors. > > For example, USB 3.1 is coming, and the updated xHCI driver will need to > return a new BOS descriptor on top of the current SuperSpeed USB Device > Capability BOS descriptor. The SuperSpeedPlus USB Device Capability BOS > descriptor is another 12 bytes long. This is why I suggested increasing the size of tbuf to 64. > Would you be opposed to changing the code to dynamically allocate tbuf? > Is there a reason why we would need to avoid memory allocation failing > here? Dynamic allocation would be just as good. There's no reason to avoid memory allocation failure here. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
