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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 52BB5CCA486 for ; Mon, 27 Jun 2022 12:08:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238812AbiF0MI2 (ORCPT ); Mon, 27 Jun 2022 08:08:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41934 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240409AbiF0MHl (ORCPT ); Mon, 27 Jun 2022 08:07:41 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8A4D0F2C for ; Mon, 27 Jun 2022 05:05:57 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 2481D61506 for ; Mon, 27 Jun 2022 12:05:57 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 05B32C3411D; Mon, 27 Jun 2022 12:05:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1656331556; bh=67Ik/eoZyJhS4eBAvMTvEKN7fzs6K6+e5ThzPYKP6E8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=YKBPjpLNmgzfGN4jLiBJCgfjCdGHGsXDDq+A3qCBepae9zbc6mOY3mr9U1DbdM1AR ENFacF4IrU0GjGasW62YqHBf5dVRgQIl7SFTcbZrTzSHjvVEbFjG/uFfij602T1fkB eziPNjLqh/dASBe4VXHXECmLymwq7yUcSrHZPYds= Date: Mon, 27 Jun 2022 13:44:48 +0200 From: Greg Kroah-Hartman To: Michael Nazzareno Trimarchi Cc: Felipe Balbi , USB list Subject: Re: f_hid GET_REPORT extension Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-usb@vger.kernel.org On Mon, Jun 27, 2022 at 10:02:27AM +0200, Michael Nazzareno Trimarchi wrote: > Hi Greg > > On Mon, Jun 27, 2022 at 9:21 AM Greg Kroah-Hartman > wrote: > > > > On Mon, Jun 27, 2022 at 09:06:05AM +0200, Michael Nazzareno Trimarchi wrote: > > > Hi Felipe and Greg > > > > > > I'm starting to write some code to extend the GET_REPORT and let the > > > userspace on the device side to pre-fill the answer on this request. > > > Right now the answer is always 0. The idea is to create a sysfs > > > support to fill reports struct on report request on the host side. > > > This will help to > > > emulate devices that export features report for example. As far as I > > > understand the hidg side just use read and write and read is used to > > > extract > > > the result of SET_REPORT is that the gadget is properly configured. Is > > > it the right direction? > > > > Without code, it is very hard to understand what you are doing here, > > sorry. > > > > Agree, I need only a suggestion what is the best way to expose it > > > Also, why sysfs? > > Let me clarify this point. Right now the userspace manage the set_report > > static ssize_t f_hidg_read(struct file *file, char __user *buffer, > size_t count, loff_t *ptr) > { > struct f_hidg *hidg = file->private_data; > > if (hidg->use_out_ep) > return f_hidg_intout_read(file, buffer, count, ptr); > else > return f_hidg_ssreport_read(file, buffer, count, ptr); > } > > The report can be write from usb side and read on gadget side if use_out_ep > is 0 (this is a configuration). Now, the answer to set_report is done > sync on request > and the usb message is buffered on the kernel side. During the > get_report as far I understand we should reply > the same way on bus. The idea is handle the type and report number and > find it on a list of report that must be prepared > on the gadget side. The hidg ops interface need to handle report > preparation so I was thinking in two solutions: > - sysfs kind of interface > - ioctl like interface sysfs is good for "one value per file", but not good for interactions where you have back/forth from userspace to the kernel. ioctls are good for "do something in the kernel and get this value back" type of operation. configfs is good for initializing data for something before you "finalize" it. So it all depends on what your userspace interaction is going to be here as to what interface to use. prototype it and see what works. greg k-h