Received: by 2002:a05:6a10:1d13:0:0:0:0 with SMTP id pp19csp2500487pxb; Tue, 24 Aug 2021 00:07:50 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz2OKePPM5UmIukvA5BbRPllF0ZFvyWe8yHGFMwnUd0bzmWRJJTpqij80NCMLwAUPH2vSuA X-Received: by 2002:a05:6402:49a:: with SMTP id k26mr41371264edv.279.1629788870218; Tue, 24 Aug 2021 00:07:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1629788870; cv=none; d=google.com; s=arc-20160816; b=o7oy+Nm418uojjX0nUVKWiR2q3L97z/MY2QL9J0iTjen6/9dSigbh6CRS2/gE0Nrog eRTU1rzpAUXi/MpBhwKYVbbvC/FRaeDl/SIv/XZEQg9f0G/Rd2dQ+ozYvWYJBr32d6pE mcwOC5wPO0ZTbVk+XfXUK50o1zfQrXrmO4s1tdicAR64VsFj7NamcCyJDk6FUEhcyshc +ThJBQ+Ut6a1E/ATdRUhSqwNe4x8ctFyPn+frFZVS/WlEtCuoN2/glNiic4scBtErQmj g39gyrTYodMKTZM63/J9PJHLbaRyon3wdvNs9T/EeUOz1ISkXw9CskZoFz3tpatw0s4v Xceg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:in-reply-to:date:subject :cc:to:from:user-agent:references:dkim-signature; bh=eYV/ymhb7DWDRsJDGoK2EDmYPociUNO91CsfeYk6/cw=; b=zgwQriFLnFfXKxgVJkDiZk0jKxjj13iW2qzHWceEVSW8z/vmbu6prIaYePCEfUu2OG evARi00F7Hqje8NnA0pWRnoLkq2U4aQYbv87ieVQlotZlJK4t27mX4ErhdI2Msq4n1Q9 SK8gACvsYTb8fcFzJXaa4Ewdb2FsDmIe7yNCYxLsRY/x+tu0Y3Cj8xQ5P+eGBa7X1gXy Fwqa5lgVk394+g+0Bb9yTe3htzpO+Dm4AEb8kwDCvRLGFVgBIvGaneGxs9I6+12AgV/G AAOKOF2teKdRMXQcjNXXLwMjwMjkwrTLhaOQDcSQlWnoEC4WrytvLAIsYYIwGF/YXQaz ECfQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=IGQJPw85; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id e1si16713195eji.452.2021.08.24.00.07.27; Tue, 24 Aug 2021 00:07:50 -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=pass header.i=@kernel.org header.s=k20201202 header.b=IGQJPw85; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232343AbhHXHGz (ORCPT + 99 others); Tue, 24 Aug 2021 03:06:55 -0400 Received: from mail.kernel.org ([198.145.29.99]:48796 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231332AbhHXHGy (ORCPT ); Tue, 24 Aug 2021 03:06:54 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 5DD6361165; Tue, 24 Aug 2021 07:06:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1629788771; bh=AUmPzVyVIdkBzP1TcX09gdv462g7bmFGWS7nBwof6EY=; h=References:From:To:Cc:Subject:Date:In-reply-to:From; b=IGQJPw85gSh+CTYT8Iq/6WmQqE8as8nu9AgNDV442kPh9mlyisOw/vqetiGHFthbs 1BqgqC/svEvMBXLM/o+i0hvNssDGmHrbKyitSuiGPXJDVjjIv2cFiiJiYEy0vCh6EW sRHuufcMwF+Zkio1l/wc7ywKj5/pBhUXi/TJPbK4CXymrROPhLA/ebFduhzsbnZ9XX nE9REMyuvVLiWI6fIyAqkq68fFw2eAO1MOLLkrNE3YjUQnphmZ8xJSRL9NPj06qJLD eBk2VxRzUU6ZMg4UOqCQYz6v1nCKCFr577uM9FPaDwoRDbnfQxRPWZiGcyduvjcwmD udePIG6JXBm0g== References: <20210821134004.363217-1-mdevaev@gmail.com> User-agent: mu4e 1.6.4; emacs 27.2 From: Felipe Balbi To: Maxim Devaev Cc: gregkh@linuxfoundation.org, ruslan.bilovol@gmail.com, mika.westerberg@linux.intel.com, jj251510319013@gmail.com, maze@google.com, linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3] usb: gadget: f_hid: optional SETUP/SET_REPORT mode Date: Tue, 24 Aug 2021 10:05:52 +0300 In-reply-to: <20210821134004.363217-1-mdevaev@gmail.com> Message-ID: <877dgb8gps.fsf@kernel.org> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Maxim Devaev writes: > f_hid provides the OUT Endpoint as only way for receiving reports > from the host. SETUP/SET_REPORT method is not supported, and this causes > a number of compatibility problems with various host drivers, especially > in the case of keyboard emulation using f_hid. > > - Some hosts do not support the OUT Endpoint and ignore it, > so it becomes impossible for the gadget to receive a report > from the host. In the case of a keyboard, the gadget loses > the ability to receive the status of the LEDs. > > - Some BIOSes/UEFIs can't work with HID devices with the OUT Endpoint > at all. This may be due to their bugs or incomplete implementation > of the HID standard. > For example, absolutely all Apple UEFIs can't handle the OUT Endpoint > if it goes after IN Endpoint in the descriptor and require the reverse > order (OUT, IN) which is a violation of the standard. > Other hosts either do not initialize gadgets with a descriptor > containing the OUT Endpoint completely (like some HP and DELL BIOSes > and embedded firmwares like on KVM switches), or initialize them, > but will not poll the IN Endpoint. > > This patch adds configfs option no_out_endpoint=1 to disable > the OUT Endpoint and allows f_hid to receive reports from the host > via SETUP/SET_REPORT. > > Previously, there was such a feature in f_hid, but it was replaced > by the OUT Endpoint [1] in the commit 99c515005857 ("usb: gadget: hidg: > register OUT INT endpoint for SET_REPORT"). So this patch actually > returns the removed functionality while making it optional. > For backward compatibility reasons, the OUT Endpoint mode remains > the default behaviour. > > - The OUT Endpoint mode provides the report queue and reduces > USB overhead (eliminating SETUP routine) on transmitting a report > from the host. > > - If the SETUP/SET_REPORT mode is used, there is no report queue, > so the userspace will only read last report. For classic HID devices > like keyboards this is not a problem, since it's intended to transmit > the status of the LEDs and only the last report is important. > This mode provides better compatibility with strange and buggy > host drivers. > > Both modes passed USBCV tests. Checking with the USB protocol analyzer > also confirmed that everything is working as it should and the new mode > ensures operability in all of the described cases. > > Signed-off-by: Maxim Devaev > Link: https://www.spinics.net/lists/linux-usb/msg65494.html [1] Acked-by: Felipe Balbi -- balbi