RE: [usb-storage] [PATCH/RFC] UASP enhancement to usb-storage

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> If it was a whole new driver, would there be any difficulty with attaching
> to either a BOT device or a UAS device, depending on the device's subclass
> code? Would the correct mass-storage driver get invoked somehow?

Absolutely not.

Each interface and each alternative of the interface, maps to a USBD, given
the interface class, subclass and protocol. The usb-core will either perform
a dynamic mapping by advertising the triple to each USBD and then whomever
"returned" the highest weight gets to handle the IF (less preferable), or
the more preferable, each USBD declares the IF class, subclass and protocol
it handles and its relative weight.

Thus, when the device presents IF0 alternative 0 as BOT (BBB) with two EPs,
and IF0 alternative 1 as UAS with 4 EPs, if there is a UAS USBD in the system,
the UAS IF0:1 should be preferred over the BOT one, IF0:0 (USBD is the BOT driver,
a la "usb-storage").

An abstraction layer (usb-core) sitting between the HCD and the USBD would then correctly
configure the device and interface and hand off the pipes to the USBD (in this case
implementing UAS).

    Luben
--
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

[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux