Message ID | 20240108120056.22165-5-paul@crapouillou.net |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-19464-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:37c1:b0:101:2151:f287 with SMTP id y1csp970197dyq; Mon, 8 Jan 2024 04:02:55 -0800 (PST) X-Google-Smtp-Source: AGHT+IE6IK1poDGnY4z86Hj2WmJRwvPsg+UlJ7a9GIZp0lW8DsVotkEylVRM1UVFHebQuEDjWkGt X-Received: by 2002:a17:90a:bf83:b0:28d:651:2631 with SMTP id d3-20020a17090abf8300b0028d06512631mr1534256pjs.88.1704715375630; Mon, 08 Jan 2024 04:02:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1704715375; cv=none; d=google.com; s=arc-20160816; b=z65AWgsiOcqVl3hdmzlNIUoT4lpoABq9Bq5+OsnitjKRonjtxPqXcUPBb+ifGeDqgI qThNtTxiGRUGcxIpDK/faSUfFUAeBHgebii0rovA87oOheWT5vwIGdJmPVW/n7cxLlKz JrIdDs68TvEcUYVYrkPaustuhq273c1UP5Dqq/X0cusHGGP/RhC3medDg0lWDRUcOX43 XkDENDxWgPe+MISPNa/fzjEgjTxpwkNa2bfhhG+Ah+gJPMu30pPxsMCCbW/IrWbuNVFp hfHy5+Y80Om77q8cfcrZlZCzfwmBFDBbmZmvJ6p1xeNFMxbTgxzFbNsQrKZeVWWNaAAU CFbg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :date:subject:cc:to:from:dkim-signature; bh=zL3Tp6j0FI2WH0LNy5N+K5/yV+yjLiDhRH8Apc3kyR0=; fh=uCl+pDf5A/h9/EhC2a7e6oA3XsaNDDsC5zMoVf40Kzc=; b=grHB5RNd1VH8k6CjblLE17K12K3knU1vzHOc6aJvSJhPiIoEWeOTIWTaG/bV6M/1GS z8gpVTpdUUlu5Atjw5VKImKD0GYZgmIF+swDavQXnptSGQmMtIkSz7BWiALILefbdH/E xQPF+vPmICjx1q/20Nr7YAzDFA/ME/Mm05puvAklyME+gH1qGShrylffC0dXBUqLRWhE ZX4Fqpv+UKGXdXdYYidh8HosZvONsI2Cn8uI/jOlWSqDJ3UXMlQXoj7TblMpcwik5tZ7 AIY5PY3+OixYjbWJxMYhvyw4dwZSCHR3S558oDDTJ4QLJ+QemPk+WVJikMeKG+NuZ11J IhDQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@crapouillou.net header.s=mail header.b=cgWfNFnB; spf=pass (google.com: domain of linux-kernel+bounces-19464-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-19464-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=crapouillou.net Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [2604:1380:45e3:2400::1]) by mx.google.com with ESMTPS id p11-20020a17090b010b00b0028d38c793e4si3443856pjz.36.2024.01.08.04.02.55 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Jan 2024 04:02:55 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-19464-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1; Authentication-Results: mx.google.com; dkim=pass header.i=@crapouillou.net header.s=mail header.b=cgWfNFnB; spf=pass (google.com: domain of linux-kernel+bounces-19464-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-19464-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=crapouillou.net Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id B04932836E3 for <ouuuleilei@gmail.com>; Mon, 8 Jan 2024 12:02:50 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 98B4C358A4; Mon, 8 Jan 2024 12:01:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=crapouillou.net header.i=@crapouillou.net header.b="cgWfNFnB" X-Original-To: linux-kernel@vger.kernel.org Received: from aposti.net (aposti.net [89.234.176.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9B59B29412; Mon, 8 Jan 2024 12:01:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=crapouillou.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=crapouillou.net DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=crapouillou.net; s=mail; t=1704715266; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=zL3Tp6j0FI2WH0LNy5N+K5/yV+yjLiDhRH8Apc3kyR0=; b=cgWfNFnBlx8XcxRkz6PLY+lsRV8zjLvwNCEb+L6VVnv8ksJAaPibrjKhNtF2TaQWErgXH7 Y9cBoaxDQIPQTzwMdqXvjv+LRDIlmk+keUTPfMvZiGpAlwBPhtwUQ3ucK2+vQTwRu7HRpY TyoFiLpGf5rG8lSa0r3vZX5fMmkmdB0= From: Paul Cercueil <paul@crapouillou.net> To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Sumit Semwal <sumit.semwal@linaro.org>, =?utf-8?q?Christian_K=C3=B6nig?= <christian.koenig@amd.com>, Jonathan Corbet <corbet@lwn.net> Cc: Jonathan Cameron <jic23@kernel.org>, =?utf-8?q?Nuno_S=C3=A1?= <noname.nuno@gmail.com>, Michael Hennerich <Michael.Hennerich@analog.com>, Andrzej Pietrasiewicz <andrzej.p@collabora.com>, linux-usb@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org, Paul Cercueil <paul@crapouillou.net> Subject: [PATCH v3 4/4] Documentation: usb: Document FunctionFS DMABUF API Date: Mon, 8 Jan 2024 13:00:56 +0100 Message-ID: <20240108120056.22165-5-paul@crapouillou.net> In-Reply-To: <20240108120056.22165-1-paul@crapouillou.net> References: <20240108120056.22165-1-paul@crapouillou.net> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam: Yes X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1787523629955236910 X-GMAIL-MSGID: 1787523629955236910 |
Series |
usb: gadget: functionfs: DMABUF import interface
|
|
Commit Message
Paul Cercueil
Jan. 8, 2024, noon UTC
Add documentation for the three ioctls used to attach or detach
externally-created DMABUFs, and to request transfers from/to previously
attached DMABUFs.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
---
v3: New patch
---
Documentation/usb/functionfs.rst | 36 ++++++++++++++++++++++++++++++++
1 file changed, 36 insertions(+)
Comments
On 08/01/2024 13:00, Paul Cercueil wrote: > Add documentation for the three ioctls used to attach or detach > externally-created DMABUFs, and to request transfers from/to previously > attached DMABUFs. > > Signed-off-by: Paul Cercueil <paul@crapouillou.net> > > --- > v3: New patch > --- > Documentation/usb/functionfs.rst | 36 ++++++++++++++++++++++++++++++++ > 1 file changed, 36 insertions(+) Hi, I'd like to point out that this file (usb/functionfs.rst) is currently included by Documentation/subsystem-apis.rst, the top-level file for the "Kernel subsystem documentation" set of books, which describe internal APIs: "These books get into the details of how specific kernel subsystems work from the point of view of a kernel developer". However, functionfs.rst (and especially your new additions) are documenting a userspace API, so it really belongs somewhere in Documentation/userspace-api/ -- that's where /proc, /sys, /dev and ioctl descriptions for userspace programmers belong. I'm not NAKing the patch -- I just want to draw attention to this discrepancy. Maybe we can separate the kernel-implementation details (stuff about __init sections and stuff) from the new ioctl() info? Looking at <https://docs.kernel.org/usb/> I see that there are many other adjacent documents that are also not really documenting kernel implementation details, rough categorization as follows: USB support ----------- - Linux ACM driver v0.16 ==> admin/user info - Authorizing (or not) your USB devices to connect to the system ==> admin/user info - ChipIdea Highspeed Dual Role Controller Driver => admin/user info - DWC3 driver ==> driver TODOs (can be moved into source code?) - EHCI driver ==> technical info + driver details - How FunctionFS works - Linux USB gadget configured through configfs ==> userspace API + implementation - Linux USB HID gadget driver ==> implementation + userspace API - Multifunction Composite Gadget ==> technical + user info - Linux USB Printer Gadget Driver ==> userspace API - Linux Gadget Serial Driver v2.0 ==> user/admin + userspace API - Linux UVC Gadget Driver ==> user/admin + userspace API - Gadget Testing ==> user/admin + userspace API - Infinity Usb Unlimited Readme ==> user/admin - Mass Storage Gadget (MSG) ==> user/admin - USB 7-Segment Numeric Display ==> user/admin - mtouchusb driver ==> user/admin - OHCI ==> technical info - USB Raw Gadget ==> userspace API - USB/IP protocol ==> technical info - usbmon ==> user/admin + userspace API - USB serial ==> user/admin + technical info - USB references - Linux CDC ACM inf - Linux inf - USB devfs drop permissions source - Credits By "admin/user info", I mean things that a user would have to do or run (e.g. modprobe + flags) to make use of a driver; "technical info" is more like device specifications (transfer speeds, modes of operation, etc.); "userspace API" is stuff like configfs and ioctls; "driver details" is really implementation details and internal considerations. The last ones I don't even really know how to categorize. I'm guessing nobody is really enthralled by the idea of splitting Documentation/usb/ up like this? Documentation/admin-guide/usb/ Documentation/driver-api/usb/ (this one actually exists already) Documentation/userspace-api/usb/ For the stuff that is _actually_ internal to a specific driver (so not useful for end users, not useful for admins, not generic USB info, and not useful for userspace programmers), I would honestly propose to just move it directly into the driver's source code, or, if the text is obsolete, just get rid of it completely. The distinction between user/admin and userspace API is pretty clear (one is for end users, the other is for userspace _programmers_), but it can sometimes be hard to determine whether something falls in one or the other category. In any case -- it looks like almost all of the usb/ directory does not document "how specific kernel subsystems work from the point of view of a kernel developer" so maybe we should just move the include to userspace-api/ for now as an obvious improvement (if still not 100% correct): diff --git a/Documentation/subsystem-apis.rst b/Documentation/subsystem-apis.rst index 2d353fb8ea26..fe972f57bf4c 100644 --- a/Documentation/subsystem-apis.rst +++ b/Documentation/subsystem-apis.rst @@ -81,7 +81,6 @@ Storage interfaces security/index crypto/index bpf/index - usb/index PCI/index misc-devices/index peci/index diff --git a/Documentation/userspace-api/index.rst b/Documentation/userspace-api/index.rst index 82f9dbd228f5..e60cd9174ada 100644 --- a/Documentation/userspace-api/index.rst +++ b/Documentation/userspace-api/index.rst @@ -41,6 +41,7 @@ Subsystem-specific documentation: tee isapnp dcdbas + ../usb/index Kernel ABIs: These documents describe the the ABI between the Linux kernel and userspace, and the relative stability of these interfaces. Thoughts? Vegard
Hi Vegard, Le mardi 09 janvier 2024 à 14:08 +0100, Vegard Nossum a écrit : > On 08/01/2024 13:00, Paul Cercueil wrote: > > Add documentation for the three ioctls used to attach or detach > > externally-created DMABUFs, and to request transfers from/to > > previously > > attached DMABUFs. > > > > Signed-off-by: Paul Cercueil <paul@crapouillou.net> > > > > --- > > v3: New patch > > --- > > Documentation/usb/functionfs.rst | 36 > > ++++++++++++++++++++++++++++++++ > > 1 file changed, 36 insertions(+) > > Hi, > > I'd like to point out that this file (usb/functionfs.rst) is > currently > included by Documentation/subsystem-apis.rst, the top-level file for > the > "Kernel subsystem documentation" set of books, which describe > internal > APIs: "These books get into the details of how specific kernel > subsystems work from the point of view of a kernel developer". > > However, functionfs.rst (and especially your new additions) are > documenting a userspace API, so it really belongs somewhere in > Documentation/userspace-api/ -- that's where /proc, /sys, /dev and > ioctl > descriptions for userspace programmers belong. Agreed. Even the original content prior to my additions describe a userspace API. > > I'm not NAKing the patch -- I just want to draw attention to this > discrepancy. Maybe we can separate the kernel-implementation details > (stuff about __init sections and stuff) from the new ioctl() info? > > Looking at <https://docs.kernel.org/usb/> I see that there are many > other adjacent documents that are also not really documenting kernel > implementation details, rough categorization as follows: > > USB support > ----------- > > - Linux ACM driver v0.16 ==> admin/user info > - Authorizing (or not) your USB devices to connect to the system ==> > admin/user info > - ChipIdea Highspeed Dual Role Controller Driver => admin/user info > - DWC3 driver ==> driver TODOs (can be moved into source code?) > - EHCI driver ==> technical info + driver details > - How FunctionFS works > - Linux USB gadget configured through configfs ==> userspace API + > implementation > - Linux USB HID gadget driver ==> implementation + userspace API > - Multifunction Composite Gadget ==> technical + user info > - Linux USB Printer Gadget Driver ==> userspace API > - Linux Gadget Serial Driver v2.0 ==> user/admin + userspace API > - Linux UVC Gadget Driver ==> user/admin + userspace API > - Gadget Testing ==> user/admin + userspace API > - Infinity Usb Unlimited Readme ==> user/admin > - Mass Storage Gadget (MSG) ==> user/admin > - USB 7-Segment Numeric Display ==> user/admin > - mtouchusb driver ==> user/admin > - OHCI ==> technical info > - USB Raw Gadget ==> userspace API > - USB/IP protocol ==> technical info > - usbmon ==> user/admin + userspace API > - USB serial ==> user/admin + technical info > - USB references > - Linux CDC ACM inf > - Linux inf > - USB devfs drop permissions source > - Credits > > By "admin/user info", I mean things that a user would have to do or > run > (e.g. modprobe + flags) to make use of a driver; "technical info" is > more like device specifications (transfer speeds, modes of operation, > etc.); "userspace API" is stuff like configfs and ioctls; "driver > details" is really implementation details and internal > considerations. > > The last ones I don't even really know how to categorize. > > I'm guessing nobody is really enthralled by the idea of splitting > Documentation/usb/ up like this? > > Documentation/admin-guide/usb/ > Documentation/driver-api/usb/ (this one actually exists already) > Documentation/userspace-api/usb/ > > For the stuff that is _actually_ internal to a specific driver (so > not > useful for end users, not useful for admins, not generic USB info, > and > not useful for userspace programmers), I would honestly propose to > just > move it directly into the driver's source code, or, if the text is > obsolete, just get rid of it completely. > > The distinction between user/admin and userspace API is pretty clear > (one is for end users, the other is for userspace _programmers_), but > it > can sometimes be hard to determine whether something falls in one or > the > other category. > > In any case -- it looks like almost all of the usb/ directory does > not > document "how specific kernel subsystems work from the point of view > of > a kernel developer" so maybe we should just move the include to > userspace-api/ for now as an obvious improvement (if still not 100% > correct): > > diff --git a/Documentation/subsystem-apis.rst > b/Documentation/subsystem-apis.rst > index 2d353fb8ea26..fe972f57bf4c 100644 > --- a/Documentation/subsystem-apis.rst > +++ b/Documentation/subsystem-apis.rst > @@ -81,7 +81,6 @@ Storage interfaces > security/index > crypto/index > bpf/index > - usb/index > PCI/index > misc-devices/index > peci/index > diff --git a/Documentation/userspace-api/index.rst > b/Documentation/userspace-api/index.rst > index 82f9dbd228f5..e60cd9174ada 100644 > --- a/Documentation/userspace-api/index.rst > +++ b/Documentation/userspace-api/index.rst > @@ -41,6 +41,7 @@ Subsystem-specific documentation: > tee > isapnp > dcdbas > + ../usb/index > > Kernel ABIs: These documents describe the the ABI between the Linux > kernel and userspace, and the relative stability of these > interfaces. > > > Thoughts? Makes sense to me. There's definitely some cleanup to be done in the USB documentation. > Vegard Cheers, -Paul
diff --git a/Documentation/usb/functionfs.rst b/Documentation/usb/functionfs.rst index a3054bea38f3..d05a775bc45b 100644 --- a/Documentation/usb/functionfs.rst +++ b/Documentation/usb/functionfs.rst @@ -2,6 +2,9 @@ How FunctionFS works ==================== +Overview +======== + From kernel point of view it is just a composite function with some unique behaviour. It may be added to an USB configuration only after the user space driver has registered by writing descriptors and @@ -66,3 +69,36 @@ have been written to their ep0's. Conversely, the gadget is unregistered after the first USB function closes its endpoints. + +DMABUF interface +================ + +FunctionFS additionally supports a DMABUF based interface, where the +userspace can attach DMABUF objects (externally created) to an endpoint, +and subsequently use them for data transfers. + +A userspace application can then use this interface to share DMABUF +objects between several interfaces, allowing it to transfer data in a +zero-copy fashion, for instance between IIO and the USB stack. + +As part of this interface, three new IOCTLs have been added. These three +IOCTLs have to be performed on a data endpoint (ie. not ep0). They are: + + ``FUNCTIONFS_DMABUF_ATTACH(int)`` + Attach the DMABUF object, identified by its file descriptor, to the + data endpoint. Returns zero on success, and a negative errno value + on error. + + ``FUNCTIONFS_DMABUF_DETACH(int)`` + Detach the given DMABUF object, identified by its file descriptor, + from the data endpoint. Returns zero on success, and a negative + errno value on error. Note that closing the endpoint's file + descriptor will automatically detach all attached DMABUFs. + + ``FUNCTIONFS_DMABUF_TRANSFER(struct usb_ffs_dmabuf_transfer_req *)`` + Enqueue the previously attached DMABUF to the transfer queue. + The argument is a structure that packs the DMABUF's file descriptor, + the size in bytes to transfer (which should generally correspond to + the size of the DMABUF), and a 'flags' field which is unused + for now. Returns zero on success, and a negative errno value on + error.