On Fri, 12 Jun 2009, Alek Du wrote: > Alan, > > Could you also give comments to this patch? I think it won't hurt other HCDs. > The QH is per EP, so it only wastes a little bytes. I count 21 wasted bytes per QH. That isn't a tremendous number. But would it be better if you could find another way to pack the data values? For instance, suppose you changed u8 qh_state; to u32 qh_state:8; To tell the truth, I don't know if this would be better or worse. Or if it would even work (gcc might generate an 8-bit access rather than a 32-bit access). Another possibility, although it would entail a lot more work, would be to separate the hardware and software portions of ehci_qh into two different structures. The hardware part would be allocated in SRAM and the software part would be allocated in regular memory. The advantage (on non-x86 architectures) would be that now the software part could be cached. One thing is certain: You need to document in the header file the requirement for 32-bit alignment. Otherwise somebody will change the structure in the future and break your systems. 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
