Received: by 2002:a05:6a10:1d13:0:0:0:0 with SMTP id pp19csp1960764pxb; Mon, 23 Aug 2021 08:38:33 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyN6kOj4/n3ZD+T1YjPLwtfK22dFnrRsXF4n1AWsJpS9eIjjjAw55h2lcq5TZtZpO+pa6VP X-Received: by 2002:a17:906:8a6a:: with SMTP id hy10mr36588360ejc.319.1629733113379; Mon, 23 Aug 2021 08:38:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1629733113; cv=none; d=google.com; s=arc-20160816; b=HFCsWY7YFu0gckR0v5yRSRkVE/1DaybxbAfmm2Jxz0qWaf844G2ourL1ys+YNcA19m /av8NNfzJz5mdC5dyIRy8/iDLXaFL/0cE5zEzglkgi+Mo73s0xsDRRySeS7VfP//gVKw GFCxCENbnThm7ODbd/mRnyqqZ6ZxdG6fYi0YEhJm+I2WhZZ7ywwQkTsL2RERTPhpSiu5 lOzGxEMdoXPVZPU1SM/W7thJT9pto68x1Zvc7k8F3ZNsqplHA6BDRijPwycc1gC+642o LNiwAaBuL/5vZmK/tphEnQtgTbYTurLwYrZNYbvbFgzrxFVX9Oe6BmlJjokuLsxt7uC4 lhzA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject:dkim-signature:dkim-signature; bh=KeD/ctI7cf6AVhOQ8x6AFFWKTh8iz1W3cGyNAVbfGPk=; b=K4Vl1e1kW4xLt2mnAeHPJDjkN7lILqVGjeHMo2GcbpOdZy87Tnvr6YsiDKg6gEqUIo 95wxLisNh+m3GLtUB71MgKBwaXdoB3Kjlrdv3aKfC3fmlV29ve3dYy7UTmGztm4dDf4Y 2dazZXO2869VKmMdITWJRKCuHdF2ijWHqoB7mv4P6X/1P25iBoq5ZlXXVgverNvL/E7c JmFdBJNBTBx+/y8OR573dM2VfELMFY3EbH9d37NtEhGWE6bs/lsFLqu3RaV2dumiEmG+ 1urrpfucYmqoUURZNavFM5uZFIEieHroS91D13nsIn2NXBaUNXAHCsfJ8Uen5KU17C/a 4urA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@ivitera.com header.s=mail header.b=e3WtZkJ+; dkim=fail header.i=@ivitera.com header.s=mail header.b=WB5t4Xbl; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ka11si14331760ejc.367.2021.08.23.08.38.08; Mon, 23 Aug 2021 08:38:33 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=fail header.i=@ivitera.com header.s=mail header.b=e3WtZkJ+; dkim=fail header.i=@ivitera.com header.s=mail header.b=WB5t4Xbl; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231337AbhHWPft (ORCPT + 99 others); Mon, 23 Aug 2021 11:35:49 -0400 Received: from cable.insite.cz ([84.242.75.189]:35716 "EHLO cable.insite.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229550AbhHWPfs (ORCPT ); Mon, 23 Aug 2021 11:35:48 -0400 Received: from localhost (localhost [127.0.0.1]) by cable.insite.cz (Postfix) with ESMTP id A1C22A1A3D401; Mon, 23 Aug 2021 17:35:03 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ivitera.com; s=mail; t=1629732903; bh=SKl+1OU3I2/IxPmHfYtCxQ37Xk2PlE5N3RRXvJkEs9k=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=e3WtZkJ+KoyoYTb30+95n55y8UL7+1y0HPK9zxlhJM7HcdKIClUyzLEiYwklZubP7 DUaZpiL/tMEmrcExwKa5Q0Lc/9O4Snf9tuzMat5loXtEqsmPoAUhdCWAIgmu2wsjIJ Bjmd0ZYZMwUPyKnX5yXmjmjZPhogp6dXMTsE2Skg= Received: from cable.insite.cz ([84.242.75.189]) by localhost (server.insite.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 88qAUBiwhYwe; Mon, 23 Aug 2021 17:34:58 +0200 (CEST) Received: from [192.168.105.22] (ip28.insite.cz [81.0.237.28]) (Authenticated sender: pavel) by cable.insite.cz (Postfix) with ESMTPSA id 7B179A1A3D400; Mon, 23 Aug 2021 17:34:57 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ivitera.com; s=mail; t=1629732897; bh=SKl+1OU3I2/IxPmHfYtCxQ37Xk2PlE5N3RRXvJkEs9k=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=WB5t4XblPMA9XR7Q2ZoTTox43KYsDIS9qrv6cz8xE2TIqDHaHlrZ08q3D1yIFXfpA dAFHvO1TZKy88Yin2Q1KqQh/gbOhEtJrRE0F7Y997NtIllgISvMfBN9mR3GTxQ2Lvu u9cG0708dc2Z/eV3FTED6XbMaLM8Sj6tlJsXhYco= Subject: Re: [PATCH v10 0/6] Re-introduce TX FIFO resize for larger EP bursting To: Andy Shevchenko Cc: Ferry Toth , Felipe Balbi , Wesley Cheng , gregkh@linuxfoundation.org, robh+dt@kernel.org, agross@kernel.org, bjorn.andersson@linaro.org, frowand.list@gmail.com, linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-msm@vger.kernel.org, jackp@codeaurora.org, heikki.krogerus@linux.intel.com, Ruslan Bilovol References: <1623923899-16759-1-git-send-email-wcheng@codeaurora.org> <87v951ldlt.fsf@kernel.org> <87pmv9l1dv.fsf@kernel.org> <9dc6cd83-17b9-7075-0934-6b9d41b6875d@gmail.com> <87a6mbudvc.fsf@kernel.org> <6e8bb4ad-fe68-ad36-7416-2b8e10b6ae96@gmail.com> <877dhev68a.fsf@kernel.org> <874kchvcq0.fsf@kernel.org> <8735raj766.fsf@kernel.org> <1fb52c92-9319-c035-722f-695ab34723dd@gmail.com> <702c72cd-40e4-e641-797a-764e7e611afb@ivitera.com> From: Pavel Hofman Message-ID: Date: Mon, 23 Aug 2021 17:34:57 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Dne 23. 08. 21 v 17:21 Andy Shevchenko napsal(a): > On Mon, Aug 23, 2021 at 5:59 PM Pavel Hofman wrote: >> Dne 22. 08. 21 v 21:43 Ferry Toth napsal(a): >>> Op 19-08-2021 om 23:04 schreef Pavel Hofman: >>>> Dne 19. 08. 21 v 22:10 Ferry Toth napsal(a): >>>>> Op 19-08-2021 om 09:51 schreef Pavel Hofman: >>>>>> Dne 18. 08. 21 v 21:07 Ferry Toth napsal(a): >>>>>>> Op 18-08-2021 om 00:00 schreef Ferry Toth: > > ... > >>>>>>> So, where do we go from here? >>>>>> >>>>>> I know the patches have been tested on dwc2 (by me and others). I >>>>>> do not know if Ruslan or Jerome tested them on dwc3 but probably >>>>>> not. Ruslan has talked about RPi (my case too) and BeagleboneBlack, >>>>>> both with dwc2. Perhaps the dwc2 behaves a bit differently than dwc3? >>>>>> >>>>>> The patches add a new EP-IN for async feedback. I am sorry I have >>>>>> not followed your long thread (it started as unrelated to uac). Does >>>>>> the problem appear with f_uac1 or f_uac2? Please how have you >>>>>> reached the above problem? >>>>> >>>>> I'm sorry too. I first believed the issue was related to the patch >>>>> mentioned in the subject line. >>>>> >>>>> The problem appaers with f_uac2. I bost Edison_Arduino board in host >>>>> mode (there is a switch allowing to select host/device mode). When >>>>> flipping the switch to device mode udev run a script: >>>>> But as I am using configfs (excerpt follows) and just disabling the >>>>> last 2 line resolves the issue, I'm guessing uac2 is the issue. Or >>>>> exceeding the available resources. >>>>> >>>>> # Create directory structure >>>>> mkdir "${GADGET_BASE_DIR}" >>>>> cd "${GADGET_BASE_DIR}" >>>>> mkdir -p configs/c.1/strings/0x409 >>>>> mkdir -p strings/0x409 >>>>> >>>>> # Serial device >>>>> mkdir functions/gser.usb0 >>>>> ln -s functions/gser.usb0 configs/c.1/ >>>>> ### >>>>> >>>>> # Ethernet device >>>>> mkdir functions/eem.usb0 >>>>> echo "${DEV_ETH_ADDR}" > functions/eem.usb0/dev_addr >>>>> echo "${HOST_ETH_ADDR}" > functions/eem.usb0/host_addr >>>>> ln -s functions/eem.usb0 configs/c.1/ >>>>> >>>>> # Mass Storage device >>>>> mkdir functions/mass_storage.usb0 >>>>> echo 1 > functions/mass_storage.usb0/stall >>>>> echo 0 > functions/mass_storage.usb0/lun.0/cdrom >>>>> echo 0 > functions/mass_storage.usb0/lun.0/ro >>>>> echo 0 > functions/mass_storage.usb0/lun.0/nofua >>>>> echo "${USBDISK}" > functions/mass_storage.usb0/lun.0/file >>>>> ln -s functions/mass_storage.usb0 configs/c.1/ >>>>> >>>>> # UAC2 device >>>>> mkdir functions/uac2.usb0 >>>>> ln -s functions/uac2.usb0 configs/c.1 >>>>> .... >>>> >>>> As you say, could perhaps the reason be that the extra EP-IN added in >>>> those patches (previously 1, now 2 with the default config you use) >>>> exceeds your EP-IN max count or available fifos somehow? You have a >>>> number of functions initialized. If you change the load order of the >>>> functions, do you get the error later with a different function? Just >>>> guessing... >>>> >>>> You should be able to switch the default async EP-OUT (which >>>> configures the new feedback EP-IN ) to adaptive EP-OUT (which requires >>>> no feedback EP) with c_sync=8 parameter of f_uac2. >>>> >>>> https://elixir.bootlin.com/linux/v5.14-rc6/source/drivers/usb/gadget/function/f_uac2.c#L47 >>>> >>>> https://elixir.bootlin.com/linux/v5.14-rc6/source/drivers/usb/gadget/function/f_uac2.c#L830 >>>> >>>> https://elixir.bootlin.com/linux/v5.14-rc6/source/include/uapi/linux/usb/ch9.h#L453 >>>> >>>> Does that fix the problem? >>> >>> Not sure how to do that. Do you mean the module should have a parameter >>> called c_sync? `modinfo` list no parameters for usb_f_uac2. >> >> Those are configfs params, not available in modinfo. >> >> I checked and the value is "adaptive" >> https://elixir.bootlin.com/linux/v5.14-rc7/source/drivers/usb/gadget/function/f_uac2.c#L1312 > >> In your configfs script: > > Kernel shouldn't crash with any available set of configuration > parameters, right? So, even if the parameter would fix the crash the > series is buggy and has to be reverted in my opinion. Sure, no problem with reverting. I am just trying to start up some troubleshooting. A resource exhaustion was mentioned here, that's why I suggested a way to test the patch with the original number of endpoints allocated. I do not get any crashes on my setup which uses fewer gadget functions. That's why I asked what happens if the functions load order is changed. I am afraid this thread is so complex that the actual problem has been burried in the history. Again, I am not the author of the patches, my USB knowledge is way unsufficient for that. I am trying to make them work as they are important and make the existing audio gadget actually usable. Thanks, Pavel.