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
