Re: f_mass_storage vs drivers/target

2019-08-25 Thread Benjamin Herrenschmidt
On Fri, 2019-08-23 at 11:21 -0400, Alan Stern wrote: > > I wonder since f_tcm is also the only user, whether we could change > > the > > matching logic to either: > > > >- Don't try to match, return streams is available. This could be > > problematic if the UDC supports streams on some EPs and

Re: f_mass_storage vs drivers/target

2019-08-23 Thread Alan Stern
On Fri, 23 Aug 2019, Benjamin Herrenschmidt wrote: > On Thu, 2019-08-22 at 13:30 -0400, Alan Stern wrote: > > On Thu, 22 Aug 2019, Benjamin Herrenschmidt wrote: > > > > > On Thu, 2019-08-22 at 14:58 +1000, Benjamin Herrenschmidt wrote: > > > > > > > > Ah lovely ... the 338x fails in EP autoconf

Re: f_mass_storage vs drivers/target

2019-08-22 Thread Benjamin Herrenschmidt
On Thu, 2019-08-22 at 13:30 -0400, Alan Stern wrote: > On Thu, 22 Aug 2019, Benjamin Herrenschmidt wrote: > > > On Thu, 2019-08-22 at 14:58 +1000, Benjamin Herrenschmidt wrote: > > > > > > Ah lovely ... the 338x fails in EP autoconf with f_tcm, digging... > > > > > > While digging I found this g

Re: f_mass_storage vs drivers/target

2019-08-22 Thread Alan Stern
On Thu, 22 Aug 2019, Benjamin Herrenschmidt wrote: > On Thu, 2019-08-22 at 14:58 +1000, Benjamin Herrenschmidt wrote: > > > > Ah lovely ... the 338x fails in EP autoconf with f_tcm, digging... > > > > While digging I found this gem: > > > > /* USB3380: use same address for usb and hardware

Re: f_mass_storage vs drivers/target

2019-08-21 Thread Benjamin Herrenschmidt
On Thu, 2019-08-22 at 15:14 +1000, Benjamin Herrenschmidt wrote: > - No UDC driver other than dummy sets max_streams, and f_tcm requires 4, > so f_tcm will fail with *any* superspeed UDC driver as far as I can tell. > > Was it ever tested with USB 3 ? Ok so I spoke too soon... dwc3 does, I didn't

Re: f_mass_storage vs drivers/target

2019-08-21 Thread Benjamin Herrenschmidt
On Thu, 2019-08-22 at 14:58 +1000, Benjamin Herrenschmidt wrote: > > Ah lovely ... the 338x fails in EP autoconf with f_tcm, digging... > > While digging I found this gem: > > /* USB3380: use same address for usb and hardware endpoints */ > snprintf(name, sizeof(name), "ep%d%s", usb_

Re: f_mass_storage vs drivers/target

2019-08-21 Thread Benjamin Herrenschmidt
On Thu, 2019-08-22 at 10:10 +1000, Benjamin Herrenschmidt wrote: > On Wed, 2019-08-21 at 10:25 -0400, Alan Stern wrote: > > On Wed, 21 Aug 2019, Benjamin Herrenschmidt wrote: > > > > > Hi folks ! > > > > > > It seems that f_mass_storage duplicates (well maybe predates too..) > > > > a > > > lot

Re: f_mass_storage vs drivers/target

2019-08-21 Thread Benjamin Herrenschmidt
On Wed, 2019-08-21 at 10:25 -0400, Alan Stern wrote: > On Wed, 21 Aug 2019, Benjamin Herrenschmidt wrote: > > > Hi folks ! > > > > It seems that f_mass_storage duplicates (well maybe predates too..) > a > > lot of what's in drivers/target. > > > > Anybody working on implementing a new version of

Re: f_mass_storage vs drivers/target

2019-08-21 Thread Alan Stern
On Wed, 21 Aug 2019, Benjamin Herrenschmidt wrote: > Hi folks ! > > It seems that f_mass_storage duplicates (well maybe predates too..) a > lot of what's in drivers/target. > > Anybody working on implementing a new version of f_mass_storage that > is layered upon drivers/target instead ? That wo

Re: f_mass_storage vs drivers/target

2019-08-21 Thread Greg KH
On Wed, Aug 21, 2019 at 01:38:49PM +1000, Benjamin Herrenschmidt wrote: > Hi folks ! > > It seems that f_mass_storage duplicates (well maybe predates too..) a > lot of what's in drivers/target. It predates it by a long time. > Anybody working on implementing a new version of f_mass_storage that