On Sunday 21 June 2009, Alek Du wrote: > > The ehci_qh structure merged hw and sw together which is not good: Call it a tradeoff. The details have been evolving over time. ;) > 1. More and more items are being added into ehci_qh, the ehci_qh software > part are unnecessary to be allocated in DMA qh_pool. Not necessary, no; but it's much simpler to do it that way. > 2. If HCD has local SRAM, the sw part will consume it too, and it won't > bring any benefit. Same point can be made for having the 64-bit pointer fields. Will you be making those more optional in later patches? > 3. For non-x86 system, the entire ehci_qh is uncachable, actually we > only need the hw part to be uncacheable. Split them will give the sw > part cacheable feature. Actually not *all* x86 systems are DMA-incoherent. Just most of them. But I'll be glad to see this, since more ARMs are incorporating EHCI hardware on their on-chip non-PCI busses. In principle I don't object. But ... this email was over 40K, which exceeds my current review time limit for this lowlevel type of change. Could you split this into smaller and more reviewable chunks? An example might be adding qh->hw pointing to QH, and then having lots of purely cosmetic changes to use that syntax where it's appropriate. Then qh->sw, likewise. And later patches could make the more substantive changes, in many fewer locations that are a lot easier to review. -- 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
