From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.1 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 24C62C433EF for ; Fri, 24 Sep 2021 08:35:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0BF5160F41 for ; Fri, 24 Sep 2021 08:35:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244714AbhIXIhF (ORCPT ); Fri, 24 Sep 2021 04:37:05 -0400 Received: from cable.insite.cz ([84.242.75.189]:55426 "EHLO cable.insite.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244640AbhIXIg7 (ORCPT ); Fri, 24 Sep 2021 04:36:59 -0400 Received: from localhost (localhost [127.0.0.1]) by cable.insite.cz (Postfix) with ESMTP id DA652A1A3D401; Fri, 24 Sep 2021 10:35:17 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ivitera.com; s=mail; t=1632472517; bh=lvZnpfWC8usU/bo0m+tM8RpmNRYpppbmXZLe8xcB1AM=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=dmByYXL4NfVL9kssPkHX+Qcm6zcfYQ9CGKmm08KECo/oiYU6aCFoQGvuIgrFx6D1d MYsFFNaSK3/wS8EpiPK9LpwcCYJL7IJg6suiz2ijWrWZ0367wp4wTPAHUxt3JnWC3r txSqFVCi7XeO+KTIZ8NN62M3ppGJzZBymv6gpA9w= 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 6TP5DphcPBq1; Fri, 24 Sep 2021 10:35:12 +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 2C94CA1A3D400; Fri, 24 Sep 2021 10:35:12 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ivitera.com; s=mail; t=1632472512; bh=lvZnpfWC8usU/bo0m+tM8RpmNRYpppbmXZLe8xcB1AM=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=g5JStdN6PBlhjJt47bN1B99aSkBfxzvY24bQQNKRJejb4it2IRNyPM6CpIPNv21Yh XdHaFWIcm+t+KfeRc02JiqG0MOiBAq9knyC8NYsxibC1J3R+0SmDUwWn1XMsQFTbDU YNPosvMyAa50P3BQwGLVJTpNf/L6fawI2wfuHM8Q= Subject: Re: [PATCH] usb: gadget: f_uac2: fixed EP-IN wMaxPacketSize To: Greg KH Cc: linux-usb@vger.kernel.org, Ruslan Bilovol , Felipe Balbi , Jerome Brunet , Jack Pham References: <20210924080027.5362-1-pavel.hofman@ivitera.com> From: Pavel Hofman Message-ID: <5c99651b-a0a2-cb44-e1ad-a79283449ce5@ivitera.com> Date: Fri, 24 Sep 2021 10:35:07 +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=iso-8859-2; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-usb@vger.kernel.org Hi Greg, Dne 24. 09. 21 v 10:20 Greg KH napsal(a): > On Fri, Sep 24, 2021 at 10:00:27AM +0200, Pavel Hofman wrote: >> Async feedback patches broke enumeration on Windows 10 previously fixed >> by commit 789ea77310f0 ("usb: gadget: f_uac2: always increase endpoint >> max_packet_size by one audio slot"). >> >> While the existing calculation for EP OUT capture for async mode yields >> size+1 frame due to uac2_opts->fb_max > 0, playback side lost the +1 >> feature. Therefore the +1 frame addition must be re-introduced for >> playback. Win10 enumerates the device only when both EP IN and EP OUT >> max packet sizes are (at least) +1 frame. >> >> Signed-off-by: Pavel Hofman >> Tested-by: Henrik Enquist >> Tested-by: Jack Pham >> --- >> drivers/usb/gadget/function/f_uac2.c | 14 ++++++++++---- >> 1 file changed, 10 insertions(+), 4 deletions(-) > > What commit does this fix? > > Should it go to stable kernel(s)? It's the same effort direction as commit https://kernel.googlesource.com/pub/scm/linux/kernel/git/gregkh/usb/+/f5dfd98a80ff8d50cf4ae2820857d7f5a46cbab9 which you added to your usb-linus branch https://kernel.googlesource.com/pub/scm/linux/kernel/git/gregkh/usb/+log/refs/heads/usb-linus/drivers/usb/gadget/function Therefore I would say usb-linus. Please what are your rules for usb-linus and usb-next? There are some different commits in usb-next and usb-linus changing the same file - f_uac2.c . Likely not, but a conflict could potentially occur. I do not know what head to rebase my further patches which also make larger changes to that file. Thanks a lot for explanation, Pavel.