On 19/08/2019 17:19, Alan Stern wrote:
> On Mon, 19 Aug 2019, Roger Quadros wrote:
>
>> On 15/08/2019 17:39, Alan Stern wrote:
>>> On Thu, 15 Aug 2019, Roger Quadros wrote:
>>>
>>>> Felipe & Alan,
>>>>
>>>> On 21/07/2019 21:32, Pawel Laszczak wrote:
>>>>> This patch introduce new Cadence USBSS DRD driver to linux kernel.
>>>>>
>>>>> The Cadence USBSS DRD Controller is a highly configurable IP Core which
>>>>> can be instantiated as Dual-Role Device (DRD), Peripheral Only and
>>>>> Host Only (XHCI)configurations.
>>>>>
>>>>> The current driver has been validated with FPGA burned. We have support
>>>>> for PCIe bus, which is used on FPGA prototyping.
>>>>>
>>>>> The host side of USBSS-DRD controller is compliance with XHCI
>>>>> specification, so it works with standard XHCI Linux driver.
>>>>
>>>> While testing this driver I encountered the following issue if I do the following.
>>>>
>>>> 1) USB port is "otg" and nothing connected so it is in IDLE mode to begin with.
>>>> i.e. HCD & UDC not registered.
>>>>
>>>> 2) Load mass storage gadget with backing medium.
>>>> > modprobe g_mass_storage file=lun stall=0
>>>>
>>>> [ 28.172142] udc-core: couldn't find an available UDC - added [g_mass_storage] to list of pending drivers
>>>>
>>>> 3) Connect port to PC host
>
> ...
>
>>>> [ 30.786313] Mass Storage Function, version: 2009/09/11
>>>> [ 30.791455] LUN: removable file: (no medium)
>>>> [ 31.039497] lun0: unable to open backing file: 500M.bin
>
>>>> Is opening the backing file from irq_thread_fn the issue here?
>>>> If yes, how to resolve this?
>>>
>>> I would guess that it probably is related to that.
>>>
>>> In any case, the backing filename should be an explicit complete path.
>>> Who knows what the current directory will be when the actual open call
>>> takes place?
>>
>> This seems to be the case. It works fine with complete path.
>>
>> Do we need to care about this in the mass storage gadget or just
>> rely on the user to provide the full path?
>
> I think it's okay to rely on the user to provide the full path.
Makes sense. But kernel shouldn't segfault like so when
user unloads g_mass_storage soon after.
[ 36.120594] Mass Storage Function, version: 2009/09/11
[ 36.125734] LUN: removable file: (no medium)
[ 36.130466] lun0: unable to open backing file: 100M.bin
[ 36.135731] g_mass_storage 6000000.usb: failed to start g_mass_storage: -2
[ 36.142664] cdns-usb3 6000000.usb: Failed to register USB device controller
[ 36.149640] cdns-usb3 6000000.usb: set 2 has failed, back to 0root@am65xx-evm:~# modprobe -r g_mass_storage
[ 60.900431] Unable to handle kernel paging request at virtual address dead000000000108
[ 60.908346] Mem abort info:
[ 60.911145] ESR = 0x96000044
[ 60.914227] Exception class = DABT (current EL), IL = 32 bits
[ 60.920162] SET = 0, FnV = 0
[ 60.923217] EA = 0, S1PTW = 0
[ 60.926354] Data abort info:
[ 60.929228] ISV = 0, ISS = 0x00000044
[ 60.933058] CM = 0, WnR = 1
[ 60.936011] [dead000000000108] address between user and kernel address ranges
[ 60.943136] Internal error: Oops: 96000044 [#1] PREEMPT SMP
[ 60.948691] Modules linked in: g_mass_storage(-) usb_f_mass_storage libcomposite xhci_plat_hcd xhci_hcd usbcore ti_am335x_adc kfifo_buf omap_rng cdns3 rng_core udc_core crc32_ce xfrm_user crct10dif_ce snd_so6
[ 60.993995] Process modprobe (pid: 834, stack limit = 0x00000000c2aebc69)
[ 61.000765] CPU: 0 PID: 834 Comm: modprobe Not tainted 4.19.59-01963-g065f42a60499 #92
[ 61.008658] Hardware name: Texas Instruments K3 J721E SoC (DT)
[ 61.014472] pstate: 60000005 (nZCv daif -PAN -UAO)
[ 61.019253] pc : usb_gadget_unregister_driver+0x7c/0x108 [udc_core]
[ 61.025503] lr : usb_gadget_unregister_driver+0x30/0x108 [udc_core]
[ 61.031750] sp : ffff00001338fda0
[ 61.035049] x29: ffff00001338fda0 x28: ffff800846d40000
[ 61.040346] x27: 0000000000000000 x26: 0000000000000000
[ 61.045642] x25: 0000000056000000 x24: 0000000000000800
[ 61.050938] x23: ffff000008d7b0d0 x22: ffff0000088b07c8
[ 61.056234] x21: ffff000001100000 x20: ffff000002020260
[ 61.061530] x19: ffff0000010ffd28 x18: 0000000000000000
[ 61.066825] x17: 0000000000000000 x16: 0000000000000000
[ 61.072121] x15: 0000000000000000 x14: 0000000000000000
[ 61.077417] x13: ffff000000000000 x12: ffffffffffffffff
[ 61.082712] x11: 0000000000000030 x10: 7f7f7f7f7f7f7f7f
[ 61.088008] x9 : fefefefefefefeff x8 : 0000000000000000
[ 61.093304] x7 : ffffffffffffffff x6 : 000000000000ffff
[ 61.098599] x5 : 8080000000000000 x4 : 0000000000000000
[ 61.103895] x3 : ffff000001100020 x2 : ffff800846d40000
[ 61.109190] x1 : dead000000000100 x0 : dead000000000200
[ 61.114486] Call trace:
[ 61.116922] usb_gadget_unregister_driver+0x7c/0x108 [udc_core]
[ 61.122828] usb_composite_unregister+0x10/0x18 [libcomposite]
[ 61.128643] msg_cleanup+0x18/0xfce0 [g_mass_storage]
[ 61.133682] __arm64_sys_delete_module+0x17c/0x1f0
[ 61.138458] el0_svc_common+0x90/0x158
[ 61.142192] el0_svc_handler+0x2c/0x80
[ 61.145926] el0_svc+0x8/0xc
[ 61.148794] Code: eb03003f d10be033 54ffff21 a94d0281 (f9000420)
[ 61.154869] ---[ end trace afb22e9b637bd9a7 ]---
Segmentation fault
The fix for this is below. I will post a patch for it separately.
diff --git a/drivers/usb/gadget/udc/core.c b/drivers/usb/gadget/udc/core.c
index af88b48c1cea..85b08756c724 100644
--- a/drivers/usb/gadget/udc/core.c
+++ b/drivers/usb/gadget/udc/core.c
@@ -1137,7 +1137,7 @@ static int check_pending_gadget_drivers(struct usb_udc *udc)
if (!driver->udc_name || strcmp(driver->udc_name,
dev_name(&udc->dev)) == 0) {
ret = udc_bind_to_driver(udc, driver);
- if (ret != -EPROBE_DEFER)
+ if (!ret)
list_del(&driver->pending);
break;
}
cheers,
-roger
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
