On Thu, 5 Feb 2009, Julie Zhu wrote:
> Thanks, Alan, for the explanations.
>
> I guess my question is what we should do if our host controller has
> integrated transaction translator but no USBMOD register. I guess we can
> put in a dumb register and do nothing.
>
> Another question, about ehci_port_speed(). We cannot use the existing 26
> offset, as hard-coded in ehci_port_speed():
>
> static inline unsigned int
> ehci_port_speed(struct ehci_hcd *ehci, unsigned int portsc)
> {
> if (ehci_is_TDI(ehci)) {
> switch ((portsc>>26)&3) {
>
> Because it may get us into copyright issues. Can we define our own
> offset bit, for example:
>
> #define EHCI_TT_SPEED_BITS 26
>
> #ifdef CONFIG_XPS_USB2_HCD_XILINX
> #define EHCI_TT_SPEED_BITS 28
> #endif
>
> static inline unsigned int
> ehci_port_speed(struct ehci_hcd *ehci, unsigned int portsc)
> {
> if (ehci_is_TDI(ehci)) {
> switch ((portsc>>EHCI_TT_SPEED_BITS)&3) {
>
> Is it acceptable to Linux?
This is really something you should discuss with Xilinx's lawyers. But
you asked for my opinion, so here it is...
The idea that you can sidestep a copyright violation by using 28
instead of 26 is ludicrous. Nobody has a copyright on the number 26.
If you're worried about infringing on somebody else's intellectual
property, I don't think changing one number will be enough to avoid the
issue.
If you really intend to design and market your own version of the
"integrated-TT" controller, then it's most likely a mistake to vary the
programming interface. This will cause market fragmentation and will
help nobody.
For example, what will happen in a system that has two EHCI controllers
made by separate vendors, each with a different layout of bits in the
port status registers? Then a single #define would never work.
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
