Re: Eject event when using USB Mass Storage Gadget
Hi Alan, On Mon, Feb 11, 2019 at 8:00 PM Alan Stern wrote: > > On Mon, 11 Feb 2019, Martin Townsend wrote: > > > I can confirm that do_start_stop is called and the code where it > > closes the LUN captures the EJECT (tested using Linux and Windows > > host). > > > > up_read(&common->filesem); > > down_write(&common->filesem); > > printk(KERN_ERR "do_start_stop -> fsg_lun_close (EJECT)\n"); > > fsg_lun_close(curlun); > > up_write(&common->filesem); > > down_read(&common->filesem); > > > > Thank you very much for this as we were about to abandon MSG :) > > > > I have one more problem, if I specify removable=y I can't re-insert > > the device and after reading the documentation it looks like I have to > > reset the backing file attribute in sysfs but I can't seem to write to > > the file attribute: > > root@beeker:/sys/module/g_mass_storage/parameters# ls -la > > total 0 > > drwxr-xr-x 2 root root0 Feb 4 19:16 . > > drwxr-xr-x 6 root root0 Feb 4 19:15 .. > > -r--r--r-- 1 root root 4096 Feb 4 19:16 bcdDevice > > -r--r--r-- 1 root root 4096 Feb 4 19:16 cdrom > > -r--r--r-- 1 root root 4096 Feb 4 19:16 file > > -r--r--r-- 1 root root 4096 Feb 4 19:16 iManufacturer > > -r--r--r-- 1 root root 4096 Feb 4 19:16 iProduct > > -r--r--r-- 1 root root 4096 Feb 4 19:16 iSerialNumber > > -r--r--r-- 1 root root 4096 Feb 4 19:16 idProduct > > -r--r--r-- 1 root root 4096 Feb 4 19:16 idVendor > > -r--r--r-- 1 root root 4096 Feb 4 19:16 luns > > -r--r--r-- 1 root root 4096 Feb 4 19:16 nofua > > -r--r--r-- 1 root root 4096 Feb 4 19:16 removable > > -r--r--r-- 1 root root 4096 Feb 4 19:16 ro > > -r--r--r-- 1 root root 4096 Feb 4 19:16 stall > > > > Even if I set the file to writable I just get an IO error. > > root@beeker:/sys/module/g_mass_storage/parameters# chmod 666 file > > root@beeker:/sys/module/g_mass_storage/parameters# echo > > /data/mass_storage/msg.bin > file > > -sh: echo: write error: Input/output error > > > > Any ideas as to why I'm seeing this? If I remove and reinsert the > > g_mass_storage gadget kernel module I can re-insert the device. I > > would like to build the gadget driver into the kernel as mass storage > > is the only gadget function we have and I believe it can be built into > > the kernel if this is the case. > > You're trying to write to the wrong sysfs file. > /sys/module/g_mass_storage/parameters contains the parameters that you > specified when g_mass_storage was loaded; you can't change them. The > file you want is > > /sys/class/udc/XXX/device/gadget/lun0/file > > (fill in the XXX with the appropriate name for your UDC). > oops. thanks for clearing that up for me :) > Alan Stern >
Re: Eject event when using USB Mass Storage Gadget
Hi Alan, On Mon, Feb 11, 2019 at 5:28 PM Alan Stern wrote: > > On Mon, 11 Feb 2019, Martin Townsend wrote: > > > Hi, > > > > I've been trying to find a way of informing user space that the eject > > button has been pressed on the host PC. I put some debug in > > do_scsi_command and I only see the TEST_UNIT_READY command with > > nothing in it to distinguish it from other TEST_UNIT_READY commands. > > After loading the gadget kernel module with removable=y I then see > > commands with id 0x03 Request Sense but reading up on this I can't see > > how this would help either. > > The host computer should send a START-STOP command when it wants to > eject the media. > > > Is there anywhere else in the mass storage gadget code that is called > > when the media has been ejected event occurs. > > fsg_lun_close(). That routine gets called from do_start_stop() when an > eject event occurs. (It also gets called from some other places in > other circumstances, such as when the gadget driver is unloaded.) > > > Failing that is there > > any other way I could poll something something from userspace say is > > sysfs that could be used to detect that the host has finished with the > > backing file/eject media has occurred. > > No, that's pretty much it. > > Alan Stern > > > Many Thanks in advance, > > Martin. > I can confirm that do_start_stop is called and the code where it closes the LUN captures the EJECT (tested using Linux and Windows host). up_read(&common->filesem); down_write(&common->filesem); printk(KERN_ERR "do_start_stop -> fsg_lun_close (EJECT)\n"); fsg_lun_close(curlun); up_write(&common->filesem); down_read(&common->filesem); Thank you very much for this as we were about to abandon MSG :) I have one more problem, if I specify removable=y I can't re-insert the device and after reading the documentation it looks like I have to reset the backing file attribute in sysfs but I can't seem to write to the file attribute: root@beeker:/sys/module/g_mass_storage/parameters# ls -la total 0 drwxr-xr-x 2 root root0 Feb 4 19:16 . drwxr-xr-x 6 root root0 Feb 4 19:15 .. -r--r--r-- 1 root root 4096 Feb 4 19:16 bcdDevice -r--r--r-- 1 root root 4096 Feb 4 19:16 cdrom -r--r--r-- 1 root root 4096 Feb 4 19:16 file -r--r--r-- 1 root root 4096 Feb 4 19:16 iManufacturer -r--r--r-- 1 root root 4096 Feb 4 19:16 iProduct -r--r--r-- 1 root root 4096 Feb 4 19:16 iSerialNumber -r--r--r-- 1 root root 4096 Feb 4 19:16 idProduct -r--r--r-- 1 root root 4096 Feb 4 19:16 idVendor -r--r--r-- 1 root root 4096 Feb 4 19:16 luns -r--r--r-- 1 root root 4096 Feb 4 19:16 nofua -r--r--r-- 1 root root 4096 Feb 4 19:16 removable -r--r--r-- 1 root root 4096 Feb 4 19:16 ro -r--r--r-- 1 root root 4096 Feb 4 19:16 stall Even if I set the file to writable I just get an IO error. root@beeker:/sys/module/g_mass_storage/parameters# chmod 666 file root@beeker:/sys/module/g_mass_storage/parameters# echo /data/mass_storage/msg.bin > file -sh: echo: write error: Input/output error Any ideas as to why I'm seeing this? If I remove and reinsert the g_mass_storage gadget kernel module I can re-insert the device. I would like to build the gadget driver into the kernel as mass storage is the only gadget function we have and I believe it can be built into the kernel if this is the case. Thanks Again, Martin.
Eject event when using USB Mass Storage Gadget
Hi, I've been trying to find a way of informing user space that the eject button has been pressed on the host PC. I put some debug in do_scsi_command and I only see the TEST_UNIT_READY command with nothing in it to distinguish it from other TEST_UNIT_READY commands. After loading the gadget kernel module with removable=y I then see commands with id 0x03 Request Sense but reading up on this I can't see how this would help either. Is there anywhere else in the mass storage gadget code that is called when the media has been ejected event occurs. Failing that is there any other way I could poll something something from userspace say is sysfs that could be used to detect that the host has finished with the backing file/eject media has occurred. Many Thanks in advance, Martin.
SH7760 OHCI
Hi, A while back I was having problems with get the USB Host driver working for the SH7760. I have fixed this problem, it was down to the roothub.a register. So now the OHCI HCD tries to communicate with the host controller on the SH7760 but now there are memory issues. The SH7760 has 8KB of shared memory that the CPU and Host controller must use. The HCCA must occupy the first 256 bytes so we don't even have 2 full page worth. Then to make matters worse there's an errata in the SH7760 hardware manual meaning the last 4 bytes of each page cannot be used. Anyway I tried declaring this region as DMA coherent memory for the OHCI device driver but as you can guess it failed when trying to alloc a new page for a TD after successfully allocating the only page available for the first ED. Although I can see a way of hacking a memory manager over the shared memory region and then putting some ugly hacks in the OHCI code to use it I would really like to get this in mainline so I wondered if anyone has any ideas how I can make this shared memory work with the current OHCI implementation before I do so. Many Thanks, Martin. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: SuperH 7760 OHCI
On Thu, May 26, 2016 at 8:04 PM, Alan Stern wrote: > On Thu, 26 May 2016, Martin Townsend wrote: > >> >> and setting the HCD_MEMORY_LOCAL flag in the HC driver. >> > >> > Did you do this correctly? That is, in the correct driver? >> > >> I put the code for the declaring the DMA coherent memory into ohci-platform.c >> and set the flag in ohci-hcd.c > > Okay. It's not portable, but it's fine for a single system with only > one controller. > >> >> and I get the following error >> > >> > ... >> >> [1.51] usb 1-1: new full-speed USB device number 2 using >> >> ohci-platform >> >> [1.69] usb 1-1: device descriptor read/64, error -12 >> >> [1.98] usb 1-1: device descriptor read/64, error -12 >> >> [2.27] usb 1-1: new full-speed USB device number 3 using >> >> ohci-platform >> >> [2.45] usb 1-1: device descriptor read/64, error -12 >> >> [2.74] usb 1-1: device descriptor read/64, error -12 >> >> [3.03] usb 1-1: new full-speed USB device number 4 using >> >> ohci-platform >> >> [3.45] usb 1-1: device not accepting address 4, error -12 >> >> [3.63] usb 1-1: new full-speed USB device number 5 using >> >> ohci-platform >> >> [4.05] usb 1-1: device not accepting address 5, error -12 >> >> [4.05] usb usb1-port1: unable to enumerate USB device >> > >> > -12 is -ENOMEM on your system? >> Yes >> > >> > ... >> >> which looks good. Anyone have an idea as to what's wrong or what the >> >> error messages mean. I have nothing plugged into the USB ports. >> > >> > Nothing plugged into the USB ports? Then why does the system think >> > something is plugged in? It sounds like the driver is not accessing >> > the right registers. >> > >> >> Also >> >> any ideas on where to start with debugging this would be appreciated. >> > >> > What do you see in /sys/kernel/debug/usb/ohci/*/registers? >> > >> root@sh7760:~# cat /sys/kernel/debug/usb/ohci/ohci-platform/registers >> bus platform, device ohci-platform >> Generic Platform OHCI controller >> ohci_hcd >> OHCI 1.0, NO legacy support registers, rh state running >> control 0x083 HCFS=operational CBSR=3 >> cmdstatus 0x0 SOC=0 >> intrstatus 0x0024 FNO SF >> intrenable 0x805a MIE RHSC UE RD WDH >> hcca frame 0x >> fmintvl 0xa7782edf FIT FSMPS=0xa778 FI=0x2edf >> fmremaining 0x88b0 FRT FR=0x08b0 >> periodicstart 0x2a2f >> lsthresh 0x0628 >> hub poll timer off >> roothub.a 02000202 POTPGT=2 NPS NDP=2(2) >> roothub.b PPCM= DR= >> roothub.status 8002 DRWE OCI >> roothub.portstatus [0] 0x0101 PPS CCS >> roothub.portstatus [1] 0x0100 PPS >> >> Does this look sane? > > Yes, except for two things: > > The OCI bit in roothub.status indicates that an OverCurrent > condition was present at some point. > > The CCS bit in roothub.portstats[0] indicates that something > is plugged into port 1. If there really is nothing plugged > into that port then this is a hardware failure. > Hi Alan, It does look like a HW problem but I just tried the 2.6 kernel image I have with this dev kit and the USB works fine so I think it's a HW configuration issue. I need to understand the HW and 2.6 SH7760 OHCI driver a bit more especially the SH7760 specific parts. Like for instance I noticed that it cleared the NPS and set the PSM bit in the Root hub config register. Then looking at the OHCI driver noticed there was a distrust firmware flag which then alters this again. Sadly I couldn't get the access to the physical addresses from the 2.6 kernel. I'll see if I can get some cross tools and get devmem on there. The memory problem looks like a silicon bug in the SH7760, we found a document detailing that the last 4 bytes of each page can be corrupted. Also I think the OHCI driver likes to use at least a page each for the TD and ED caches which leaves nothing for the HCCA. Anyway I took the memory managment code from the 2.6 OHCI driver I have and plumbed it in to ohci-mem and then hardcoded ohci->hcca and ohci->dma_hcca to 0xFE341000 and 0x0 respectively. Don't know if it works yet as I'm still getting overcurrent indicator, at least the CCS bit isn't currently set but then again it doesn't get set when I plug something in. I was hoping this could be something that could be merged into mainline but the more I dig the more it's not looking promising. Thanks for taking the time to help, I really appreciate it. - Martin. > The reason for the ENOMEM errors isn't clear. You could try adding > some debugging statements to see exactly where it comes from. A likely > spot is the call to hcd_alloc_coherent() in usb_hcd_map_urb_for_dma(). > > Alan Stern > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: SuperH 7760 OHCI
On Thu, May 26, 2016 at 6:31 PM, Alan Stern wrote:
> On Thu, 26 May 2016, Martin Townsend wrote:
>
>> I tried hacking in the relevant code straight into the OHCI platform driver
>> res_mem = platform_get_resource(dev, IORESOURCE_MEM, 1);
>> if (res_mem == NULL) {
>> dev_err(&dev->dev, "no resource definition for memory\n");
>> err = -ENOENT;
>> goto err_power;
>> }
>>
>> if (!request_mem_region(res_mem->start, resource_size(res_mem),
>> dev->name)) {
>> dev_err(&dev->dev, "request_mem_region failed\n");
>> err = -EBUSY;
>> goto err_power;
>> }
>>
>> /*
>> * Use SH7760 Shared Memory
>> */
>> if (!dma_declare_coherent_memory(&dev->dev, res_mem->start,
>> res_mem->start - res_mem->parent->start,
>> resource_size(res_mem),
>> DMA_MEMORY_MAP |
>> DMA_MEMORY_EXCLUSIVE)) {
>> dev_err(&dev->dev, "cannot declare coherent memory\n");
>> err = -ENXIO;
>> goto err_power;
>> }
>> and setting the HCD_MEMORY_LOCAL flag in the HC driver.
>
> Did you do this correctly? That is, in the correct driver?
>
I put the code for the declaring the DMA coherent memory into ohci-platform.c
and set the flag in ohci-hcd.c
>> and I get the following error
>
> ...
>> [1.51] usb 1-1: new full-speed USB device number 2 using
>> ohci-platform
>> [1.69] usb 1-1: device descriptor read/64, error -12
>> [1.98] usb 1-1: device descriptor read/64, error -12
>> [2.27] usb 1-1: new full-speed USB device number 3 using
>> ohci-platform
>> [2.45] usb 1-1: device descriptor read/64, error -12
>> [2.74] usb 1-1: device descriptor read/64, error -12
>> [3.03] usb 1-1: new full-speed USB device number 4 using
>> ohci-platform
>> [3.45] usb 1-1: device not accepting address 4, error -12
>> [3.63] usb 1-1: new full-speed USB device number 5 using
>> ohci-platform
>> [4.05] usb 1-1: device not accepting address 5, error -12
>> [4.05] usb usb1-port1: unable to enumerate USB device
>
> -12 is -ENOMEM on your system?
Yes
>
> ...
>> which looks good. Anyone have an idea as to what's wrong or what the
>> error messages mean. I have nothing plugged into the USB ports.
>
> Nothing plugged into the USB ports? Then why does the system think
> something is plugged in? It sounds like the driver is not accessing
> the right registers.
>
>> Also
>> any ideas on where to start with debugging this would be appreciated.
>
> What do you see in /sys/kernel/debug/usb/ohci/*/registers?
>
root@sh7760:~# cat /sys/kernel/debug/usb/ohci/ohci-platform/registers
bus platform, device ohci-platform
Generic Platform OHCI controller
ohci_hcd
OHCI 1.0, NO legacy support registers, rh state running
control 0x083 HCFS=operational CBSR=3
cmdstatus 0x0 SOC=0
intrstatus 0x0024 FNO SF
intrenable 0x805a MIE RHSC UE RD WDH
hcca frame 0x
fmintvl 0xa7782edf FIT FSMPS=0xa778 FI=0x2edf
fmremaining 0x88b0 FRT FR=0x08b0
periodicstart 0x2a2f
lsthresh 0x0628
hub poll timer off
roothub.a 02000202 POTPGT=2 NPS NDP=2(2)
roothub.b PPCM= DR=
roothub.status 8002 DRWE OCI
roothub.portstatus [0] 0x0101 PPS CCS
roothub.portstatus [1] 0x0100 PPS
Does this look sane?
Cheers,
Martin.
> Alan Stern
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: SuperH 7760 OHCI
On Thu, May 26, 2016 at 4:05 PM, Martin Townsend
wrote:
> Hi,
>
> I'm currently trying to get the USB Host working on the SH7760. I
> tried the platform driver to start with and get the following error on
> boot:
> [3.60] usb 1-1: new full-speed USB device number 2 using ohci-platform
> [3.872000] ohci-platform ohci-platform: frame counter not updating;
> disabled
> [3.872000] ohci-platform ohci-platform: HC died; cleaning up
>
> So I dug a bit further and see that the SH7760 driver in the 2.6
> kernel makes use of the 8KB shared memory for HCCA and ED/TD buffers.
> After looking through the code for the 4.1 Kernel I am currently
> trying to port to I think I need to write my own platform driver that
> calls dma_declare_coherent_memory so that the OHCI driver uses this
> 8KB shared memory. Then set HCD_LOCAL_MEM in the hc_driver flags to
> ensure that it uses dma_alloc_coherent. In other words copy what the
> ohci-sm501.c file is doing. I just wanted to confirm that this is
> what I should be doing or is there a better generic way of telling the
> OHCI driver to use this 8KB shared memory.
>
I tried hacking in the relevant code straight into the OHCI platform driver
res_mem = platform_get_resource(dev, IORESOURCE_MEM, 1);
if (res_mem == NULL) {
dev_err(&dev->dev, "no resource definition for memory\n");
err = -ENOENT;
goto err_power;
}
if (!request_mem_region(res_mem->start, resource_size(res_mem),
dev->name)) {
dev_err(&dev->dev, "request_mem_region failed\n");
err = -EBUSY;
goto err_power;
}
/*
* Use SH7760 Shared Memory
*/
if (!dma_declare_coherent_memory(&dev->dev, res_mem->start,
res_mem->start - res_mem->parent->start,
resource_size(res_mem),
DMA_MEMORY_MAP |
DMA_MEMORY_EXCLUSIVE)) {
dev_err(&dev->dev, "cannot declare coherent memory\n");
err = -ENXIO;
goto err_power;
}
and setting the HCD_MEMORY_LOCAL flag in the HC driver.
and I get the following error
[1.04] Found resource sh7760-usb-irq
[1.06] Found resource sh7760-usb-shared-memory
[1.06] Found resource sh7760-usb-io-memory
[1.13] usb usb1: New USB device found, idVendor=1d6b, idProduct=0001
[1.13] usb usb1: New USB device strings: Mfr=3, Product=2,
SerialNumber=1
[1.13] usb usb1: Product: Generic Platform OHCI controller
[1.13] usb usb1: Manufacturer: Linux 4.1.17-yocto-standard ohci_hcd
[1.13] usb usb1: SerialNumber: ohci-platform
[1.13] device: 'usb1': device_add
[1.13] bus: 'usb': add device usb1
[1.13] bus: 'usb': driver_probe_device: matched device usb1
with driver usb
[1.13] bus: 'usb': really_probe: probing driver usb with device usb1
[1.13] bus: 'usb': add device 1-0:1.0
[1.13] bus: 'usb': driver_probe_device: matched device 1-0:1.0
with driver hub
[1.13] bus: 'usb': really_probe: probing driver hub with device 1-0:1.0
[1.13] device: 'usb1-port1': device_add
[1.13] device: 'usb1-port2': device_add
[1.13] bus: 'usb': really_probe: bound device 1-0:1.0 to driver hub
[1.13] driver: 'usb': driver_bound: bound to device 'usb1'
[1.13] bus: 'usb': really_probe: bound device usb1 to driver usb
[1.14] bus: 'usb': add driver usbhid
[1.14] usbcore: registered new interface driver usbhid
[1.14] usbhid: USB HID core driver
[1.51] usb 1-1: new full-speed USB device number 2 using ohci-platform
[1.69] usb 1-1: device descriptor read/64, error -12
[1.98] usb 1-1: device descriptor read/64, error -12
[2.27] usb 1-1: new full-speed USB device number 3 using ohci-platform
[2.45] usb 1-1: device descriptor read/64, error -12
[2.74] usb 1-1: device descriptor read/64, error -12
[3.03] usb 1-1: new full-speed USB device number 4 using ohci-platform
[3.45] usb 1-1: device not accepting address 4, error -12
[3.63] usb 1-1: new full-speed USB device number 5 using ohci-platform
[4.05] usb 1-1: device not accepting address 5, error -12
[4.05] usb usb1-port1: unable to enumerate USB device
Here's the board support definitions
/* No power control needed so a blank platform data */
static struct usb_ohci_pdata usb_ohci_pdata;
static u64 usb_ohci_dma_mask = 0x;
static struct resource sh7760_usb_resources[] = {
DEFINE_RES_MEM_NAMED(SH7760_USB_BASE, SH7760_USB_IOLEN,
"sh7760-usb-io-memory"),
DEFINE_RES_MEM_NAMED(SH7760_USB_SHARED_MEM_BAS
Re: SuperH 7760 OHCI
On Thu, May 26, 2016 at 4:24 PM, Alan Stern wrote: > On Thu, 26 May 2016, Martin Townsend wrote: > >> Hi, >> >> I'm currently trying to get the USB Host working on the SH7760. I >> tried the platform driver to start with and get the following error on >> boot: >> [3.60] usb 1-1: new full-speed USB device number 2 using >> ohci-platform >> [3.872000] ohci-platform ohci-platform: frame counter not updating; >> disabled >> [3.872000] ohci-platform ohci-platform: HC died; cleaning up >> >> So I dug a bit further and see that the SH7760 driver in the 2.6 >> kernel makes use of the 8KB shared memory for HCCA and ED/TD buffers. >> After looking through the code for the 4.1 Kernel I am currently >> trying to port to I think I need to write my own platform driver that >> calls dma_declare_coherent_memory so that the OHCI driver uses this >> 8KB shared memory. Then set HCD_LOCAL_MEM in the hc_driver flags to >> ensure that it uses dma_alloc_coherent. In other words copy what the >> ohci-sm501.c file is doing. I just wanted to confirm that this is >> what I should be doing or is there a better generic way of telling the >> OHCI driver to use this 8KB shared memory. > > There isn't a generic way of doing it, but you could such a thing to > the ohci-platform driver. That would be preferable to adding a new, > separate platform driver. > > Alan Stern > Hi Alan, Thanks for the reply. So would that entail looking for a second IORESOURCE_MEM resource and taking this as the device's shared memory and if present call dma_declare_coherent_memory? Also how would I or in the HCD_LOCAL_MEM to flags to the hc_driver struct that's in ohci-hcd.c? Cheers, Martin. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
SuperH 7760 OHCI
Hi, I'm currently trying to get the USB Host working on the SH7760. I tried the platform driver to start with and get the following error on boot: [3.60] usb 1-1: new full-speed USB device number 2 using ohci-platform [3.872000] ohci-platform ohci-platform: frame counter not updating; disabled [3.872000] ohci-platform ohci-platform: HC died; cleaning up So I dug a bit further and see that the SH7760 driver in the 2.6 kernel makes use of the 8KB shared memory for HCCA and ED/TD buffers. After looking through the code for the 4.1 Kernel I am currently trying to port to I think I need to write my own platform driver that calls dma_declare_coherent_memory so that the OHCI driver uses this 8KB shared memory. Then set HCD_LOCAL_MEM in the hc_driver flags to ensure that it uses dma_alloc_coherent. In other words copy what the ohci-sm501.c file is doing. I just wanted to confirm that this is what I should be doing or is there a better generic way of telling the OHCI driver to use this 8KB shared memory. Thanks in advance, Martin. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
