Re: usb-storage: how to extend quirks flags to 64bit?

[Alan Stern <stern@rowland.harvard.edu>]

On Sun, Aug 27, 2023 at 11:32:05AM +0200, Milan Broz wrote:
> Hello,
> 
> I tried to extend USB storage for the passthrough of Opal
> security commands,

What sort of changes are needed?  Where is this passthrough mechanism 
documented?

>  and some adapters are clearly "not perfect".

Which ones?

> I would need to introduce a new quirks flag to turn it off.
> 
> Seems that we are already out of quirks flags on 32bit
> for usb storage - in usb_usual.h the last entry in mainline is
>   US_FLAG(SENSE_AFTER_SYNC, 0x80000000)
> 
> Adding a new flag will work for 64-bit systems but not
> for platforms with 32-bit unsigned long like i686.
> 
> How do we allow new flag definitions?
> 
> Struct us_data fflags can be made 64bit (defined in
> drivers/usb/storage/usb.h), but the major problem is that these
> are transferred through the generic driver_info field
> defined in linux/mod_devicetable.h as unsigned long).
> Making this 64bit is IMO an extensive API change (if even possible).
> I guess this is not the way to go.
> 
> Could USB maintainers please help to advise what is the correct
> solution? I am not familiar with the USB driver model here
> and I see no easy way how it can be solved by a trivial static
> allocation inside the USB storage driver.
> 
> Someone will need a new quirks flag in the future anyway... :)

I can think of only one way to accomplish this on 32-bit systems: Change 
the driver_info field from a bit array to an index into a static table 
of 64-bit flags values.  Each unusual_devs structure would have its own 
entry in this table.  As far as I can tell, the other unusual_*.h tables
could retain their current driver_info interpretations, since no new 
quirk bits are likely to be relevant to them.

Making this change would be an awkward nuisance, but it should be 
doable.

Alan Stern