Re: [PATCH v10 0/6] Introduced new Cadence USBSS DRD Driver.

[Roger Quadros <rogerq@ti.com>]

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