From patchwork Fri Dec 4 06:20:15 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Randy Dunlap X-Patchwork-Id: 11950729 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=-18.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=unavailable 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 93D07C1B087 for ; Fri, 4 Dec 2020 06:21:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 50F9C2253D for ; Fri, 4 Dec 2020 06:21:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728153AbgLDGVR (ORCPT ); Fri, 4 Dec 2020 01:21:17 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46602 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725819AbgLDGVP (ORCPT ); Fri, 4 Dec 2020 01:21:15 -0500 Received: from merlin.infradead.org (merlin.infradead.org [IPv6:2001:8b0:10b:1231::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 84D01C061A51; Thu, 3 Dec 2020 22:20:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=merlin.20170209; h=Content-Transfer-Encoding:MIME-Version: References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:Sender:Reply-To: Content-Type:Content-ID:Content-Description; bh=tifnINnQ0NLHptCKXQmX+jamUjQmXsFh4DRr8z/8b7o=; b=JJhppijuSc3zJdSxQOsDJhUI4f QjfPHkaCManBxu7oI5OQtUSKwY0DI6CtR+FyTlBArgdQw2xHkSn0ZXu6Lea21Yw5qUgnGjucjlcO8 kMGFVFY5YsiUV5Qho6fuedw2zh9v38HNy8BwTtP87j0ag5fsDIjo9eVEHMU5b0IGGkE5V+bk4mGrw o2hPXEUhbDFDtH7u6OgVD1pDKvlOoQdlQmfSBFg8DOott1Voxa7kP71FuYwFG4G5mKKHpeTsFt9di 3AFr7gQwQ4Ja/KVsbuUDtv3M82ENapXD2zs6CVN7ljwxMEmC2DIN6Mm9G/Zix8DMmTfSGOgSxeXjW IGDQ1bXg==; Received: from [2601:1c0:6280:3f0::1494] (helo=smtpauth.infradead.org) by merlin.infradead.org with esmtpsa (Exim 4.92.3 #3 (Red Hat Linux)) id 1kl4SH-0002HZ-40; Fri, 04 Dec 2020 06:20:33 +0000 From: Randy Dunlap To: linux-kernel@vger.kernel.org Cc: Randy Dunlap , Jiri Kosina , Benjamin Tissoires , linux-input@vger.kernel.org, Jonathan Cameron , Srinivas Pandruvada , linux-iio@vger.kernel.org, Jonathan Corbet , linux-doc@vger.kernel.org Subject: [PATCH 1/8] Documentation: HID: hid-alps editing & corrections Date: Thu, 3 Dec 2020 22:20:15 -0800 Message-Id: <20201204062022.5095-2-rdunlap@infradead.org> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20201204062022.5095-1-rdunlap@infradead.org> References: <20201204062022.5095-1-rdunlap@infradead.org> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-iio@vger.kernel.org Do basic editing & correction to hid-alps.rst: - fix grammar - fix punctuation spacing Signed-off-by: Randy Dunlap Cc: Jiri Kosina Cc: Benjamin Tissoires Cc: linux-input@vger.kernel.org Cc: Jonathan Corbet Cc: linux-doc@vger.kernel.org --- Documentation/hid/hid-alps.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- linux-next-20201201.orig/Documentation/hid/hid-alps.rst +++ linux-next-20201201/Documentation/hid/hid-alps.rst @@ -64,7 +64,7 @@ Case2 ReportID_3 TP Absolute Command Read/Write ------------------ -To read/write to RAM, need to send a commands to the device. +To read/write to RAM, need to send a command to the device. The command format is as below. @@ -80,7 +80,7 @@ Byte6 Value Byte Byte7 Checksum ===== ====================== -Command Byte is read=0xD1/write=0xD2 . +Command Byte is read=0xD1/write=0xD2. Address is read/write RAM address. From patchwork Fri Dec 4 06:20:16 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Randy Dunlap X-Patchwork-Id: 11950731 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=-18.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_GIT 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 D616CC1B0D8 for ; Fri, 4 Dec 2020 06:21:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A65F922A85 for ; Fri, 4 Dec 2020 06:21:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728192AbgLDGVT (ORCPT ); Fri, 4 Dec 2020 01:21:19 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46614 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725819AbgLDGVT (ORCPT ); Fri, 4 Dec 2020 01:21:19 -0500 Received: from merlin.infradead.org (merlin.infradead.org [IPv6:2001:8b0:10b:1231::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 12EADC061A52; Thu, 3 Dec 2020 22:20:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=merlin.20170209; h=Content-Transfer-Encoding:MIME-Version: References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:Sender:Reply-To: Content-Type:Content-ID:Content-Description; bh=wRsJlxFIWj8q5aFJON2aTW63qPvnPACR49t7lFad7io=; b=qPXP8UE/AkYhiPk6J2wSXnVAtm Xb+4Nkj5d1HW/ekEMr5NOMp5ltsGfPtmPsinj7h11YlTxQqYKDbSfy9EouMjoq1eJ82/pfwFhce9u a1e9quHd0pzpLfjiPpNrXzSw/5BiOGF+O9WphZOyakQbYfbaCMbgFZt9+hRCaL04s5IEz54TiJ8ZC NlecW9ZJUuUnPqc1IyFIBLet4C0aLE+vo8r6c/gnB9m9Aj78KOjlitcJRs9Ygc7SzaOg44xDazF+H haBF/7y1QIq+aSJrMj1tYOaCOUv+gR6j+9EiY4hJmkz3oUPK3G24xf2SwVIYA/Oky5gdL3o1kFGOq O1c/HD3A==; Received: from [2601:1c0:6280:3f0::1494] (helo=smtpauth.infradead.org) by merlin.infradead.org with esmtpsa (Exim 4.92.3 #3 (Red Hat Linux)) id 1kl4SK-0002HZ-Lg; Fri, 04 Dec 2020 06:20:37 +0000 From: Randy Dunlap To: linux-kernel@vger.kernel.org Cc: Randy Dunlap , Jiri Kosina , Benjamin Tissoires , linux-input@vger.kernel.org, Jonathan Cameron , Srinivas Pandruvada , linux-iio@vger.kernel.org, Jonathan Corbet , linux-doc@vger.kernel.org Subject: [PATCH 2/8] Documentation: HID: amd-sfh-hid editing & corrections Date: Thu, 3 Dec 2020 22:20:16 -0800 Message-Id: <20201204062022.5095-3-rdunlap@infradead.org> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20201204062022.5095-1-rdunlap@infradead.org> References: <20201204062022.5095-1-rdunlap@infradead.org> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-iio@vger.kernel.org Do basic editing & correction to amd-sfh-hid.rst: - fix punctuation - use HID instead of hid consistently - fix grammar, verb tense Signed-off-by: Randy Dunlap Cc: Jiri Kosina Cc: Jonathan Cameron Cc: Srinivas Pandruvada Cc: linux-input@vger.kernel.org Cc: linux-iio@vger.kernel.org Cc: Jonathan Corbet Cc: linux-doc@vger.kernel.org --- Documentation/hid/amd-sfh-hid.rst | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) --- linux-next-20201201.orig/Documentation/hid/amd-sfh-hid.rst +++ linux-next-20201201/Documentation/hid/amd-sfh-hid.rst @@ -3,7 +3,7 @@ AMD Sensor Fusion Hub ===================== -AMD Sensor Fusion Hub (SFH) is part of an SOC starting from Ryzen based platforms. +AMD Sensor Fusion Hub (SFH) is part of an SOC starting from Ryzen-based platforms. The solution is working well on several OEM products. AMD SFH uses HID over PCIe bus. In terms of architecture it resembles ISH, however the major difference is all the HID reports are generated as part of the kernel driver. @@ -45,20 +45,20 @@ the HID reports are generated as part of AMD HID Transport Layer ----------------------- AMD SFH transport is also implemented as a bus. Each client application executing in the AMD MP2 is -registered as a device on this bus. Here: MP2 which is an ARM core connected to x86 for processing +registered as a device on this bus. Here, MP2 is an ARM core connected to x86 for processing sensor data. The layer, which binds each device (AMD SFH HID driver) identifies the device type and -registers with the hid core. Transport layer attach a constant "struct hid_ll_driver" object with +registers with the HID core. Transport layer attaches a constant "struct hid_ll_driver" object with each device. Once a device is registered with HID core, the callbacks provided via this struct are used by HID core to communicate with the device. AMD HID Transport layer implements the synchronous calls. AMD HID Client Layer -------------------- -This layer is responsible to implement HID request and descriptors. As firmware is OS agnostic, HID +This layer is responsible to implement HID requests and descriptors. As firmware is OS agnostic, HID client layer fills the HID request structure and descriptors. HID client layer is complex as it is -interface between MP2 PCIe layer and HID. HID client layer initialized the MP2 PCIe layer and holds +interface between MP2 PCIe layer and HID. HID client layer initializes the MP2 PCIe layer and holds the instance of MP2 layer. It identifies the number of sensors connected using MP2-PCIe layer. Base -on that allocates the DRAM address for each and every sensor and pass it to MP2-PCIe driver.On -enumeration of each the sensor, client layer fills the HID Descriptor structure and HID input repor +on that allocates the DRAM address for each and every sensor and passes it to MP2-PCIe driver. On +enumeration of each sensor, client layer fills the HID Descriptor structure and HID input report structure. HID Feature report structure is optional. The report descriptor structure varies from sensor to sensor. @@ -72,7 +72,7 @@ The communication between X86 and MP2 is 2. Data transfer via DRAM. 3. Supported sensor info via P2C registers. -Commands are sent to MP2 using C2P Mailbox registers. Writing into C2P Message registers generate +Commands are sent to MP2 using C2P Mailbox registers. Writing into C2P Message registers generates interrupt to MP2. The client layer allocates the physical memory and the same is sent to MP2 via the PCI layer. MP2 firmware writes the command output to the access DRAM memory which the client layer has allocated. Firmware always writes minimum of 32 bytes into DRAM. So as a protocol driver From patchwork Fri Dec 4 06:20:17 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Randy Dunlap X-Patchwork-Id: 11950733 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=-18.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_GIT autolearn=unavailable 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 33383C2BBCD for ; Fri, 4 Dec 2020 06:21:31 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id F2D4122581 for ; Fri, 4 Dec 2020 06:21:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728238AbgLDGVX (ORCPT ); Fri, 4 Dec 2020 01:21:23 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46622 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725819AbgLDGVX (ORCPT ); Fri, 4 Dec 2020 01:21:23 -0500 Received: from merlin.infradead.org (merlin.infradead.org [IPv6:2001:8b0:10b:1231::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A33DFC061A53; Thu, 3 Dec 2020 22:20:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=merlin.20170209; h=Content-Transfer-Encoding:MIME-Version: References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:Sender:Reply-To: Content-Type:Content-ID:Content-Description; bh=XmyZzzTZKCb50OlY8+NVjIQzW91Ffi5HE4HYViQP4B8=; b=ov3p+fIa3mH2n58/9GJO4pKttm +xFzFcWh2SIIuH9XxFKkThFU6+xgfo1ppp9YqRbV8brnhdGE3FtT5uDqs4YO0FwtLYf4NrZ6VHbFU NV9fqMzbQ3/BOXGIPaIIGXmOrSQQUvn0x+u7R+teaWX5XDQ19pUDo6qex+D5IXaWCh2GDN+RxCZG3 Jzl6jsRUrqRDtNNXkmiqEYPJGY++v+TL9jYgb4PBhJbzvlPe8XWeUcQk6IZG/BNZaQ7AiF4ro0vRx mpVaVTtun0257Gd0PPNUa+FZ8wzePaZTBsA0MOHU5152pZc6EJmii2aewbqORp6x/k8zaMgc3yuJJ HalU5YrA==; Received: from [2601:1c0:6280:3f0::1494] (helo=smtpauth.infradead.org) by merlin.infradead.org with esmtpsa (Exim 4.92.3 #3 (Red Hat Linux)) id 1kl4SO-0002HZ-9U; Fri, 04 Dec 2020 06:20:40 +0000 From: Randy Dunlap To: linux-kernel@vger.kernel.org Cc: Randy Dunlap , Jiri Kosina , Benjamin Tissoires , linux-input@vger.kernel.org, Jonathan Cameron , Srinivas Pandruvada , linux-iio@vger.kernel.org, Jonathan Corbet , linux-doc@vger.kernel.org Subject: [PATCH 3/8] Documentation: HID: hiddev editing & corrections Date: Thu, 3 Dec 2020 22:20:17 -0800 Message-Id: <20201204062022.5095-4-rdunlap@infradead.org> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20201204062022.5095-1-rdunlap@infradead.org> References: <20201204062022.5095-1-rdunlap@infradead.org> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-iio@vger.kernel.org Do basic editing & correction to hiddev.rst: - use HID instead of hid consistently - add hyphenation of multi-word adjectives - drop a duplicate word - unhyphenate "a priori" Signed-off-by: Randy Dunlap Cc: Jiri Kosina Cc: Benjamin Tissoires Cc: linux-input@vger.kernel.org Cc: Jonathan Corbet Cc: linux-doc@vger.kernel.org --- Documentation/hid/hiddev.rst | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) --- linux-next-20201201.orig/Documentation/hid/hiddev.rst +++ linux-next-20201201/Documentation/hid/hiddev.rst @@ -27,7 +27,7 @@ the following:: --> hiddev.c ----> POWER / MONITOR CONTROL In addition, other subsystems (apart from USB) can potentially feed -events into the input subsystem, but these have no effect on the hid +events into the input subsystem, but these have no effect on the HID device interface. Using the HID Device Interface @@ -72,8 +72,8 @@ The hiddev API uses a read() interface, HID devices exchange data with the host computer using data bundles called "reports". Each report is divided into "fields", -each of which can have one or more "usages". In the hid-core, -each one of these usages has a single signed 32 bit value. +each of which can have one or more "usages". In the HID core, +each one of these usages has a single signed 32-bit value. read(): ------- @@ -113,7 +113,7 @@ HIDIOCAPPLICATION - (none) This ioctl call returns the HID application usage associated with the -hid device. The third argument to ioctl() specifies which application +HID device. The third argument to ioctl() specifies which application index to get. This is useful when the device has more than one application collection. If the index is invalid (greater or equal to the number of application collections this device has) the ioctl @@ -181,7 +181,7 @@ looked up by type (input, output or feat must be filled in by the user. The ID can be absolute -- the actual report id as reported by the device -- or relative -- HID_REPORT_ID_FIRST for the first report, and (HID_REPORT_ID_NEXT | -report_id) for the next report after report_id. Without a-priori +report_id) for the next report after report_id. Without a priori information about report ids, the right way to use this ioctl is to use the relative IDs above to enumerate the valid IDs. The ioctl returns non-zero when there is no more next ID. The real report ID is @@ -200,7 +200,7 @@ HIDIOCGUCODE - struct hiddev_usage_ref (read/write) Returns the usage_code in a hiddev_usage_ref structure, given that -given its report type, report id, field index, and index within the +its report type, report id, field index, and index within the field have already been filled into the structure. HIDIOCGUSAGE From patchwork Fri Dec 4 06:20:18 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Randy Dunlap X-Patchwork-Id: 11950735 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=-18.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT 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 750C7C2BBD4 for ; Fri, 4 Dec 2020 06:21:31 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2FC3E2253D for ; Fri, 4 Dec 2020 06:21:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728311AbgLDGV0 (ORCPT ); Fri, 4 Dec 2020 01:21:26 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46634 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727894AbgLDGV0 (ORCPT ); Fri, 4 Dec 2020 01:21:26 -0500 Received: from merlin.infradead.org (merlin.infradead.org [IPv6:2001:8b0:10b:1231::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3A031C061A54; Thu, 3 Dec 2020 22:20:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=merlin.20170209; h=Content-Transfer-Encoding:Content-Type: MIME-Version:References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:Sender :Reply-To:Content-ID:Content-Description; bh=uCFNSWUSBtMbsT8AQMzqFgOEcOQY5MAZMnp0YpVtlgk=; b=ub0kLm3lQmCdvjsLbMxi+93Dp2 azppRjs5Y1+6lTDJMfrMsJarygwJn8mHJiYdKvL1jgDzlmnWFyNRtnZ2/hw67HbrzCN/r4fTljNjP ByynGadRUV+wys3upPkZSBkELjswwHqcBLmz3PooWktda6xqSfdiBtjtCLn2Zek5S0ey9Y8rlJonI Y0eZvoO2sUmhFqTtEAVLRHU9IOeXWs5pMr0Zx6P6rUJL3/rDTVeQkpZMDj6qy5jl3t+Tf6Fa0cjtS VgCBjBy+SEig/mx/8Rai7FO5jfhdNuciFH2+nqr6p73+WMKk3JNMWITsAb61VnDFVBCswvBsyZPUN tpVFPZeg==; Received: from [2601:1c0:6280:3f0::1494] (helo=smtpauth.infradead.org) by merlin.infradead.org with esmtpsa (Exim 4.92.3 #3 (Red Hat Linux)) id 1kl4SR-0002HZ-SJ; Fri, 04 Dec 2020 06:20:44 +0000 From: Randy Dunlap To: linux-kernel@vger.kernel.org Cc: Randy Dunlap , Jiri Kosina , Benjamin Tissoires , linux-input@vger.kernel.org, Jonathan Cameron , Srinivas Pandruvada , linux-iio@vger.kernel.org, Jonathan Corbet , linux-doc@vger.kernel.org Subject: [PATCH 4/8] Documentation: HID: intel-ish-hid editing & corrections Date: Thu, 3 Dec 2020 22:20:18 -0800 Message-Id: <20201204062022.5095-5-rdunlap@infradead.org> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20201204062022.5095-1-rdunlap@infradead.org> References: <20201204062022.5095-1-rdunlap@infradead.org> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-iio@vger.kernel.org Do basic editing & correction to intel-ish-hid.rst: - fix grammar, verb tense, punctutation, and word phrasing - fix spellos - hyphenate multi-word adjectives - collapse 2 spaces to one space in the middle of sentences - use "I2C" instead of lower-case letters (as Linux I2C does) - change space indentation to tab - use HID instead of hid consistently - use a list so that some line items do not run together - use "a UUID" instead of "an UUID" Signed-off-by: Randy Dunlap Cc: Jiri Kosina Cc: Jonathan Cameron Cc: Srinivas Pandruvada Cc: linux-input@vger.kernel.org Cc: linux-iio@vger.kernel.org Cc: Jonathan Corbet Cc: linux-doc@vger.kernel.org --- Documentation/hid/intel-ish-hid.rst | 74 +++++++++++++------------- 1 file changed, 38 insertions(+), 36 deletions(-) --- linux-next-20201201.orig/Documentation/hid/intel-ish-hid.rst +++ linux-next-20201201/Documentation/hid/intel-ish-hid.rst @@ -4,19 +4,19 @@ Intel Integrated Sensor Hub (ISH) A sensor hub enables the ability to offload sensor polling and algorithm processing to a dedicated low power co-processor. This allows the core -processor to go into low power modes more often, resulting in the increased +processor to go into low power modes more often, resulting in increased battery life. -There are many vendors providing external sensor hubs confirming to HID -Sensor usage tables, and used in several tablets, 2 in 1 convertible laptops +There are many vendors providing external sensor hubs conforming to HID +Sensor usage tables, and used in several tablets, 2-in-1 convertible laptops and embedded products. Linux had this support since Linux 3.9. Intel® introduced integrated sensor hubs as a part of the SoC starting from Cherry Trail and now supported on multiple generations of CPU packages. There are many commercial devices already shipped with Integrated Sensor Hubs (ISH). -These ISH also comply to HID sensor specification, but the difference is the +These ISH also comply to HID sensor specification, but the difference is the transport protocol used for communication. The current external sensor hubs -mainly use HID over i2C or USB. But ISH doesn't use either i2c or USB. +mainly use HID over I2C or USB. But ISH doesn't use either I2C or USB. 1. Overview =========== @@ -35,7 +35,7 @@ for a very high speed communication:: ----------------- ---------------------- PCI PCI ----------------- ---------------------- - |Host controller| --> | ISH processor | + |Host controller| --> | ISH processor | ----------------- ---------------------- USB Link ----------------- ---------------------- @@ -50,13 +50,13 @@ applications implemented in the firmware The ISH allows multiple sensor management applications executing in the firmware. Like USB endpoints the messaging can be to/from a client. As part of enumeration process, these clients are identified. These clients can be simple -HID sensor applications, sensor calibration application or senor firmware +HID sensor applications, sensor calibration application or sensor firmware update application. The implementation model is similar, like USB bus, ISH transport is also implemented as a bus. Each client application executing in the ISH processor is registered as a device on this bus. The driver, which binds each device -(ISH HID driver) identifies the device type and registers with the hid core. +(ISH HID driver) identifies the device type and registers with the HID core. 2. ISH Implementation: Block Diagram ==================================== @@ -104,7 +104,7 @@ is registered as a device on this bus. T The ISH is exposed as "Non-VGA unclassified PCI device" to the host. The PCI product and vendor IDs are changed from different generations of processors. So -the source code which enumerate drivers needs to update from generation to +the source code which enumerates drivers needs to update from generation to generation. 3.2 Inter Processor Communication (IPC) driver @@ -112,41 +112,42 @@ generation. Location: drivers/hid/intel-ish-hid/ipc -The IPC message used memory mapped I/O. The registers are defined in +The IPC message uses memory mapped I/O. The registers are defined in hw-ish-regs.h. 3.2.1 IPC/FW message types ^^^^^^^^^^^^^^^^^^^^^^^^^^ -There are two types of messages, one for management of link and other messages -are to and from transport layers. +There are two types of messages, one for management of link and another for +messages to and from transport layers. TX and RX of Transport messages ............................... -A set of memory mapped register offers support of multi byte messages TX and -RX (E.g.IPC_REG_ISH2HOST_MSG, IPC_REG_HOST2ISH_MSG). The IPC layer maintains -internal queues to sequence messages and send them in order to the FW. +A set of memory mapped register offers support of multi-byte messages TX and +RX (e.g. IPC_REG_ISH2HOST_MSG, IPC_REG_HOST2ISH_MSG). The IPC layer maintains +internal queues to sequence messages and send them in order to the firmware. Optionally the caller can register handler to get notification of completion. -A door bell mechanism is used in messaging to trigger processing in host and +A doorbell mechanism is used in messaging to trigger processing in host and client firmware side. When ISH interrupt handler is called, the ISH2HOST doorbell register is used by host drivers to determine that the interrupt is for ISH. Each side has 32 32-bit message registers and a 32-bit doorbell. Doorbell -register has the following format: -Bits 0..6: fragment length (7 bits are used) -Bits 10..13: encapsulated protocol -Bits 16..19: management command (for IPC management protocol) -Bit 31: doorbell trigger (signal H/W interrupt to the other side) -Other bits are reserved, should be 0. +register has the following format:: + + Bits 0..6: fragment length (7 bits are used) + Bits 10..13: encapsulated protocol + Bits 16..19: management command (for IPC management protocol) + Bit 31: doorbell trigger (signal H/W interrupt to the other side) + Other bits are reserved, should be 0. 3.2.2 Transport layer interface ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -To abstract HW level IPC communication, a set of callbacks are registered. +To abstract HW level IPC communication, a set of callbacks is registered. The transport layer uses them to send and receive messages. -Refer to struct ishtp_hw_ops for callbacks. +Refer to struct ishtp_hw_ops for callbacks. 3.3 ISH Transport layer ----------------------- @@ -158,7 +159,7 @@ Location: drivers/hid/intel-ish-hid/isht The transport layer is a bi-directional protocol, which defines: - Set of commands to start, stop, connect, disconnect and flow control -(ishtp/hbm.h) for details +(see ishtp/hbm.h for details) - A flow control mechanism to avoid buffer overflows This protocol resembles bus messages described in the following document: @@ -168,14 +169,14 @@ specifications/dcmi-hi-1-0-spec.pdf "Cha 3.3.2 Connection and Flow Control Mechanism ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Each FW client and a protocol is identified by an UUID. In order to communicate +Each FW client and a protocol is identified by a UUID. In order to communicate to a FW client, a connection must be established using connect request and response bus messages. If successful, a pair (host_client_id and fw_client_id) will identify the connection. Once connection is established, peers send each other flow control bus messages independently. Every peer may send a message only if it has received a -flow-control credit before. Once it sent a message, it may not send another one +flow-control credit before. Once it has sent a message, it may not send another one before receiving the next flow control credit. Either side can send disconnect request bus message to end communication. Also the link will be dropped if major FW reset occurs. @@ -209,7 +210,7 @@ and DMA_XFER_ACK act as ownership indica At initial state all outgoing memory belongs to the sender (TX to host, RX to FW), DMA_XFER transfers ownership on the region that contains ISHTP message to the receiving side, DMA_XFER_ACK returns ownership to the sender. A sender -needs not wait for previous DMA_XFER to be ack'ed, and may send another message +need not wait for previous DMA_XFER to be ack'ed, and may send another message as long as remaining continuous memory in its ownership is enough. In principle, multiple DMA_XFER and DMA_XFER_ACK messages may be sent at once (up to IPC MTU), thus allowing for interrupt throttling. @@ -219,8 +220,8 @@ fragments and via IPC otherwise. 3.3.4 Ring Buffers ^^^^^^^^^^^^^^^^^^ -When a client initiate a connection, a ring or RX and TX buffers are allocated. -The size of ring can be specified by the client. HID client set 16 and 32 for +When a client initiates a connection, a ring of RX and TX buffers is allocated. +The size of ring can be specified by the client. HID client sets 16 and 32 for TX and RX buffers respectively. On send request from client, the data to be sent is copied to one of the send ring buffer and scheduled to be sent using bus message protocol. These buffers are required because the FW may have not @@ -230,10 +231,10 @@ to send. Same thing holds true on receiv 3.3.5 Host Enumeration ^^^^^^^^^^^^^^^^^^^^^^ -The host enumeration bus command allow discovery of clients present in the FW. +The host enumeration bus command allows discovery of clients present in the FW. There can be multiple sensor clients and clients for calibration function. -To ease in implantation and allow independent driver handle each client +To ease implementation and allow independent drivers to handle each client, this transport layer takes advantage of Linux Bus driver model. Each client is registered as device on the transport bus (ishtp bus). @@ -270,7 +271,7 @@ The ISHTP client driver is responsible f The functionality in these drivers is the same as an external sensor hub. Refer to Documentation/hid/hid-sensor.rst for HID sensor -Documentation/ABI/testing/sysfs-bus-iio for IIO ABIs to user space +Documentation/ABI/testing/sysfs-bus-iio for IIO ABIs to user space. 3.6 End to End HID transport Sequence Diagram --------------------------------------------- @@ -341,9 +342,10 @@ Documentation/ABI/testing/sysfs-bus-iio 3.7 ISH Debugging ----------------- -To debug ISH, event tracing mechanism is used. To enable debug logs -echo 1 > /sys/kernel/debug/tracing/events/intel_ish/enable -cat sys/kernel/debug/tracing/trace +To debug ISH, event tracing mechanism is used. To enable debug logs:: + + echo 1 > /sys/kernel/debug/tracing/events/intel_ish/enable + cat sys/kernel/debug/tracing/trace 3.8 ISH IIO sysfs Example on Lenovo thinkpad Yoga 260 ----------------------------------------------------- From patchwork Fri Dec 4 06:20:19 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Randy Dunlap X-Patchwork-Id: 11950737 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=-18.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_GIT autolearn=unavailable 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 65627C4361A for ; Fri, 4 Dec 2020 06:22:09 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2B585225AA for ; Fri, 4 Dec 2020 06:22:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728023AbgLDGVx (ORCPT ); Fri, 4 Dec 2020 01:21:53 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46702 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727776AbgLDGVw (ORCPT ); Fri, 4 Dec 2020 01:21:52 -0500 Received: from merlin.infradead.org (merlin.infradead.org [IPv6:2001:8b0:10b:1231::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6B167C061A55; Thu, 3 Dec 2020 22:20:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=merlin.20170209; h=Content-Transfer-Encoding:MIME-Version: References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:Sender:Reply-To: Content-Type:Content-ID:Content-Description; bh=lkYTuLMVK3xD9H7nEaU3PUg6Qinz0z5CmtM+kw5zPU4=; b=jH+c22Wy24yIKOi4p5D4DkSZpO c1qUx4pZJK/icmnYLd7+KBq6G+PYGEb/0ASbAQu3pqo1ZdACSPTaaIH/A7OPsQXtoaWsqTv07YaCP W3zl58aklGWE43jgLHD15urh/YTyC803eSSXqijtE3R3Wx3qR22rbKEctZJZa483VZcyhdMca2/N8 q1nETUGyMccy5Dy+RX8cQ+UnxkxP7D9ZPBC5rzQHZYKvnAjkeaBzncu2b44WkwJB8UUu+gHMeSG/b ddyFJjP0N72s33db+0cvJWEgb76qZtsgU9QHWJI9EN1rGcNtgBh45toyHrf5uY9RdhDhvUE9FUnBP ZLORjhRg==; Received: from [2601:1c0:6280:3f0::1494] (helo=smtpauth.infradead.org) by merlin.infradead.org with esmtpsa (Exim 4.92.3 #3 (Red Hat Linux)) id 1kl4SV-0002HZ-UF; Fri, 04 Dec 2020 06:20:48 +0000 From: Randy Dunlap To: linux-kernel@vger.kernel.org Cc: Randy Dunlap , Jiri Kosina , Benjamin Tissoires , linux-input@vger.kernel.org, Jonathan Cameron , Srinivas Pandruvada , linux-iio@vger.kernel.org, Jonathan Corbet , linux-doc@vger.kernel.org, Alan Ott Subject: [PATCH 5/8] Documentation: HID: hidraw editing & corrections Date: Thu, 3 Dec 2020 22:20:19 -0800 Message-Id: <20201204062022.5095-6-rdunlap@infradead.org> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20201204062022.5095-1-rdunlap@infradead.org> References: <20201204062022.5095-1-rdunlap@infradead.org> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-iio@vger.kernel.org Do basic editing & correction to hidraw.rst: - use "hidraw" consistently except at the beginning of a sentence - add archive.org URL for signal11.us since the latter seems to be MIA - use a list for 2 URLs so that they don't run together Signed-off-by: Randy Dunlap Cc: Jiri Kosina Cc: Benjamin Tissoires Cc: linux-input@vger.kernel.org Cc: Alan Ott Cc: Jonathan Corbet Cc: linux-doc@vger.kernel.org --- Documentation/hid/hidraw.rst | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) --- linux-next-20201201.orig/Documentation/hid/hidraw.rst +++ linux-next-20201201/Documentation/hid/hidraw.rst @@ -21,7 +21,7 @@ Hidraw is the only alternative, short of these non-conformant devices. A benefit of hidraw is that its use by userspace applications is independent -of the underlying hardware type. Currently, Hidraw is implemented for USB +of the underlying hardware type. Currently, hidraw is implemented for USB and Bluetooth. In the future, as new hardware bus types are developed which use the HID specification, hidraw will be expanded to add support for these new bus types. @@ -31,9 +31,10 @@ create hidraw device nodes. Udev will t directly under /dev (eg: /dev/hidraw0). As this location is distribution- and udev rule-dependent, applications should use libudev to locate hidraw devices attached to the system. There is a tutorial on libudev with a -working example at: +working example at:: http://www.signal11.us/oss/udev/ + https://web.archive.org/web/2019*/www.signal11.us The HIDRAW API --------------- From patchwork Fri Dec 4 06:20:20 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Randy Dunlap X-Patchwork-Id: 11950743 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=-18.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_GIT autolearn=unavailable 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 681C6C2BBCD for ; Fri, 4 Dec 2020 06:22:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3432C22597 for ; Fri, 4 Dec 2020 06:22:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728405AbgLDGVx (ORCPT ); Fri, 4 Dec 2020 01:21:53 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46704 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727952AbgLDGVx (ORCPT ); Fri, 4 Dec 2020 01:21:53 -0500 Received: from merlin.infradead.org (merlin.infradead.org [IPv6:2001:8b0:10b:1231::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E2107C061A56; Thu, 3 Dec 2020 22:20:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=merlin.20170209; h=Content-Transfer-Encoding:Content-Type: MIME-Version:References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:Sender :Reply-To:Content-ID:Content-Description; bh=FLeiyYcYndFk6Ks4B0qswcYUlqrq6gt+Fx7r0g+Y8ik=; b=zzLwHWxuX5I8GLqCIpWPnwFOpd je0NB1McyN7WaOOs9mkpTX3KLVVGJ5HW6T6/xrUZOxAmyNRam9hknyhXquOsrwCLZktRK+uBxjlgp fOVCCXaIThzM+T74eg+Hu7GdF/g3qa2/Y39d0JbgSV6lo5aCfDX+4cj16INypm/xbsXszCFZ1WKqh wLuziDNc2RnAkjoVgq/JVDYYeNH1rzvX0VZFt2W1gw/JoRC43A0Lh4McEYhuzhb+07k/ePw3S94Yd eeF5qA8BLswpWWp0MTYPork05/08eY7BbYOP5F42gwLOH7rG76XnH5Qhx54JJ7PrM4ZpQiVKKE4f2 dsDfpnNg==; Received: from [2601:1c0:6280:3f0::1494] (helo=smtpauth.infradead.org) by merlin.infradead.org with esmtpsa (Exim 4.92.3 #3 (Red Hat Linux)) id 1kl4SZ-0002HZ-Gt; Fri, 04 Dec 2020 06:20:52 +0000 From: Randy Dunlap To: linux-kernel@vger.kernel.org Cc: Randy Dunlap , Jiri Kosina , Benjamin Tissoires , linux-input@vger.kernel.org, Jonathan Cameron , Srinivas Pandruvada , linux-iio@vger.kernel.org, Jonathan Corbet , linux-doc@vger.kernel.org Subject: [PATCH 6/8] Documentation: HID: hid-sensor editing & corrections Date: Thu, 3 Dec 2020 22:20:20 -0800 Message-Id: <20201204062022.5095-7-rdunlap@infradead.org> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20201204062022.5095-1-rdunlap@infradead.org> References: <20201204062022.5095-1-rdunlap@infradead.org> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-iio@vger.kernel.org Do basic editing & correction to hid-sensor.rst: - use HID consistently instead of hid - drop a duplicate word - change article adjective an -> a - fix grammar & punctuation - spell out RW -> read-write - hyphenate multi-word adjectives Signed-off-by: Randy Dunlap Cc: Jiri Kosina Cc: Jonathan Cameron Cc: Srinivas Pandruvada Cc: linux-input@vger.kernel.org Cc: linux-iio@vger.kernel.org Cc: Jonathan Corbet Cc: linux-doc@vger.kernel.org --- Documentation/hid/hid-sensor.rst | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) --- linux-next-20201201.orig/Documentation/hid/hid-sensor.rst +++ linux-next-20201201/Documentation/hid/hid-sensor.rst @@ -48,12 +48,12 @@ for different sensors. For example an ac an ambient light sensor can send illumination data. So the implementation has two parts: -- Core hid driver +- Core HID driver - Individual sensor processing part (sensor drivers) Core driver ----------- -The core driver registers (hid-sensor-hub) registers as a HID driver. It parses +The core driver (hid-sensor-hub) registers as a HID driver. It parses report descriptors and identifies all the sensors present. It adds an MFD device with name HID-SENSOR-xxxx (where xxxx is usage id from the specification). @@ -95,14 +95,14 @@ Registration functions:: u32 usage_id, struct hid_sensor_hub_callbacks *usage_callback): -Registers callbacks for an usage id. The callback functions are not allowed +Registers callbacks for a usage id. The callback functions are not allowed to sleep:: int sensor_hub_remove_callback(struct hid_sensor_hub_device *hsdev, u32 usage_id): -Removes callbacks for an usage id. +Removes callbacks for a usage id. Parsing function:: @@ -166,7 +166,7 @@ This allows some differentiating use cas Some common use cases are debug other sensors or to provide some events like keyboard attached/detached or lid open/close. -To allow application to utilize these sensors, here they are exported uses sysfs +To allow application to utilize these sensors, here they are exported using sysfs attribute groups, attributes and misc device interface. An example of this representation on sysfs:: @@ -207,9 +207,9 @@ An example of this representation on sys │   │   │   ├── input-1-200202-units │   │   │   ├── input-1-200202-value -Here there is a custom sensors with four fields, two feature and two inputs. +Here there is a custom sensor with four fields: two feature and two inputs. Each field is represented by a set of attributes. All fields except the "value" -are read only. The value field is a RW field. +are read only. The value field is a read-write field. Example:: @@ -237,6 +237,6 @@ These reports are pushed using misc devi │   │   │   ├── 10:53 -> ../HID-SENSOR-2000e1.6.auto │   ├── HID-SENSOR-2000e1.6.auto -Each reports can be of variable length preceded by a header. This header -consist of a 32 bit usage id, 64 bit time stamp and 32 bit length field of raw +Each report can be of variable length preceded by a header. This header +consists of a 32-bit usage id, 64-bit time stamp and 32-bit length field of raw data. From patchwork Fri Dec 4 06:20:21 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Randy Dunlap X-Patchwork-Id: 11950739 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=-18.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_GIT 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 26223C4167B for ; Fri, 4 Dec 2020 06:22:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C733D2253D for ; Fri, 4 Dec 2020 06:22:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728477AbgLDGV5 (ORCPT ); Fri, 4 Dec 2020 01:21:57 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46720 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727952AbgLDGV4 (ORCPT ); Fri, 4 Dec 2020 01:21:56 -0500 Received: from merlin.infradead.org (merlin.infradead.org [IPv6:2001:8b0:10b:1231::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AE8F7C08C5F2; Thu, 3 Dec 2020 22:20:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=merlin.20170209; h=Content-Transfer-Encoding:MIME-Version: References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:Sender:Reply-To: Content-Type:Content-ID:Content-Description; bh=Dzqd9oWAlypnBUcaG3+r48ufax/PraL0ot/F6/P6l7w=; b=tM22K/DvSjtAesgLcQpHIW7ji9 ItRk6lPuHIrurRLsyxFTpiz7meGhsxJ9AzPUpWxKvGrWfY7c4jDxK2wOTIxO8HZB2a+UvSAr7sCgQ PA7x9Uj1g0NmndvexVT3v1GJS/+HaI/sy3+y7M3VEl+3NkOpK7StCa2zoDqCxakEdMTKSzqpaPUTz UbR4f9kKqFcct1LwynHspEzLpO1oiOOjH8q+6JVe436Xi2AvLg/levGSh4FWmDdB3kSBDePmNNcoJ FLZUxoDqZd1qtbyPV5BA4Df+Sh1+oO7R9omNDyeeSjg0sygfwjRsSHh7HLl0pABcz7pF5fsgnyYa5 onhgQKPw==; Received: from [2601:1c0:6280:3f0::1494] (helo=smtpauth.infradead.org) by merlin.infradead.org with esmtpsa (Exim 4.92.3 #3 (Red Hat Linux)) id 1kl4Sd-0002HZ-Az; Fri, 04 Dec 2020 06:20:55 +0000 From: Randy Dunlap To: linux-kernel@vger.kernel.org Cc: Randy Dunlap , Jiri Kosina , Benjamin Tissoires , linux-input@vger.kernel.org, Jonathan Cameron , Srinivas Pandruvada , linux-iio@vger.kernel.org, Jonathan Corbet , linux-doc@vger.kernel.org, David Herrmann Subject: [PATCH 7/8] Documentation: HID: hid-transport editing & corrections Date: Thu, 3 Dec 2020 22:20:21 -0800 Message-Id: <20201204062022.5095-8-rdunlap@infradead.org> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20201204062022.5095-1-rdunlap@infradead.org> References: <20201204062022.5095-1-rdunlap@infradead.org> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-iio@vger.kernel.org Do basic editing & correction to hid-transport.rst: - s/responsible of/responsible for/ - fix grammar & punctuation Signed-off-by: Randy Dunlap Cc: Jiri Kosina Cc: Benjamin Tissoires Cc: linux-input@vger.kernel.org Cc: David Herrmann Cc: Jonathan Corbet Cc: linux-doc@vger.kernel.org --- Documentation/hid/hid-transport.rst | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) --- linux-next-20201201.orig/Documentation/hid/hid-transport.rst +++ linux-next-20201201/Documentation/hid/hid-transport.rst @@ -12,8 +12,8 @@ Bluetooth, I2C and user-space I/O driver The HID subsystem is designed as a bus. Any I/O subsystem may provide HID devices and register them with the HID bus. HID core then loads generic device -drivers on top of it. The transport drivers are responsible of raw data -transport and device setup/management. HID core is responsible of +drivers on top of it. The transport drivers are responsible for raw data +transport and device setup/management. HID core is responsible for report-parsing, report interpretation and the user-space API. Device specifics and quirks are handled by all layers depending on the quirk. @@ -67,7 +67,7 @@ Transport drivers attach a constant "str device. Once a device is registered with HID core, the callbacks provided via this struct are used by HID core to communicate with the device. -Transport drivers are responsible of detecting device failures and unplugging. +Transport drivers are responsible for detecting device failures and unplugging. HID core will operate a device as long as it is registered regardless of any device failures. Once transport drivers detect unplug or failure events, they must unregister the device from HID core and HID core will stop using the @@ -101,7 +101,7 @@ properties in common. channel. Any unrequested incoming or outgoing data report must be sent on this channel and is never acknowledged by the remote side. Devices usually send their input events on this channel. Outgoing events are normally - not send via intr, except if high throughput is required. + not sent via intr, except if high throughput is required. - Control Channel (ctrl): The ctrl channel is used for synchronous requests and device management. Unrequested data input events must not be sent on this channel and are normally ignored. Instead, devices only send management @@ -161,7 +161,7 @@ allowed on the intr channel and are the payload may be blocked by the underlying transport driver if the specification does not allow them. - SET_REPORT: A SET_REPORT request has a report ID plus data as payload. It is - sent from host to device and a device must update it's current report state + sent from host to device and a device must update its current report state according to the given data. Any of the 3 report types can be used. However, INPUT reports as payload might be blocked by the underlying transport driver if the specification does not allow them. @@ -294,7 +294,7 @@ The available HID callbacks are: void (*request) (struct hid_device *hdev, struct hid_report *report, int reqtype) - Send an HID request on the ctrl channel. "report" contains the report that + Send a HID request on the ctrl channel. "report" contains the report that should be sent and "reqtype" the request type. Request-type can be HID_REQ_SET_REPORT or HID_REQ_GET_REPORT. From patchwork Fri Dec 4 06:20:22 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Randy Dunlap X-Patchwork-Id: 11950741 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=-18.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_GIT autolearn=unavailable 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 014D1C2BB48 for ; Fri, 4 Dec 2020 06:22:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CBC5F2253D for ; Fri, 4 Dec 2020 06:22:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728472AbgLDGV5 (ORCPT ); Fri, 4 Dec 2020 01:21:57 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46722 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728470AbgLDGV4 (ORCPT ); Fri, 4 Dec 2020 01:21:56 -0500 Received: from merlin.infradead.org (merlin.infradead.org [IPv6:2001:8b0:10b:1231::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A113CC08E85E; Thu, 3 Dec 2020 22:21:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=merlin.20170209; h=Content-Transfer-Encoding:MIME-Version: References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:Sender:Reply-To: Content-Type:Content-ID:Content-Description; bh=85a75XCalerfRjEXWXHwqX8/9O+dkhtYbWa8p+MOsLI=; b=oeJr47fZ9S9nSFIAVcEOK/HX0E IuP15/Xp+8vQERN3pRVbVg1mpp1b/UeDNWaBQwPxHpxSew7AcIArhnQatocq0gtvGc4PJgdC8Zr9L aTh9S9T/tjOTGSjuofGjRrmFzSI9avM1DeBYcCQ2FBMNiqPYmih/OloFVJHmPvOuhY3gv4yovkZ1+ dWSdlWuYtelwAa2HTCI6HsyQ8CF+rAaYMmsgfLTeudtuvxTxsF+XZz8fDKwXOWDQowqvTM0b+0TVg y/uzFG9nwDzSzXUt6bQIm/pJPJbjaaMkScEFaYVVaP+TpolE2+V+BVPSu7OCZikfeGnlq7EYz8+rS QK6j4/Yg==; Received: from [2601:1c0:6280:3f0::1494] (helo=smtpauth.infradead.org) by merlin.infradead.org with esmtpsa (Exim 4.92.3 #3 (Red Hat Linux)) id 1kl4Sh-0002HZ-43; Fri, 04 Dec 2020 06:20:59 +0000 From: Randy Dunlap To: linux-kernel@vger.kernel.org Cc: Randy Dunlap , Jiri Kosina , Benjamin Tissoires , linux-input@vger.kernel.org, Jonathan Cameron , Srinivas Pandruvada , linux-iio@vger.kernel.org, Jonathan Corbet , linux-doc@vger.kernel.org, David Herrmann Subject: [PATCH 8/8] Documentation: HID: uhid editing & corrections Date: Thu, 3 Dec 2020 22:20:22 -0800 Message-Id: <20201204062022.5095-9-rdunlap@infradead.org> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20201204062022.5095-1-rdunlap@infradead.org> References: <20201204062022.5095-1-rdunlap@infradead.org> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-iio@vger.kernel.org Do basic editing & correction to hid-alps.rst: - correct a file name (.txt -> .rst) - use less hyphenation when not needed - fix grammar & punctuation - fix article adjectives - fix typos/spellos - use HID instead of hid consistently Signed-off-by: Randy Dunlap Cc: Jiri Kosina Cc: Benjamin Tissoires Cc: linux-input@vger.kernel.org Cc: David Herrmann Cc: Jonathan Corbet Cc: linux-doc@vger.kernel.org --- Documentation/hid/uhid.rst | 34 +++++++++++++++++----------------- 1 file changed, 17 insertions(+), 17 deletions(-) --- linux-next-20201201.orig/Documentation/hid/uhid.rst +++ linux-next-20201201/Documentation/hid/uhid.rst @@ -3,7 +3,7 @@ UHID - User-space I/O driver support for ====================================================== UHID allows user-space to implement HID transport drivers. Please see -hid-transport.txt for an introduction into HID transport drivers. This document +hid-transport.rst for an introduction into HID transport drivers. This document relies heavily on the definitions declared there. With UHID, a user-space transport driver can create kernel hid-devices for each @@ -15,7 +15,7 @@ There is an example user-space applicati The UHID API ------------ -UHID is accessed through a character misc-device. The minor-number is allocated +UHID is accessed through a character misc-device. The minor number is allocated dynamically so you need to rely on udev (or similar) to create the device node. This is /dev/uhid by default. @@ -45,23 +45,23 @@ The "type" field defines the payload. Fo payload-structure available in the union "u" (except for empty payloads). This payload contains management and/or device data. -The first thing you should do is sending an UHID_CREATE2 event. This will -register the device. UHID will respond with an UHID_START event. You can now +The first thing you should do is send a UHID_CREATE2 event. This will +register the device. UHID will respond with a UHID_START event. You can now start sending data to and reading data from UHID. However, unless UHID sends the UHID_OPEN event, the internally attached HID Device Driver has no user attached. That is, you might put your device asleep unless you receive the UHID_OPEN event. If you receive the UHID_OPEN event, you should start I/O. If the last -user closes the HID device, you will receive an UHID_CLOSE event. This may be -followed by an UHID_OPEN event again and so on. There is no need to perform +user closes the HID device, you will receive a UHID_CLOSE event. This may be +followed by a UHID_OPEN event again and so on. There is no need to perform reference-counting in user-space. That is, you will never receive multiple -UHID_OPEN events without an UHID_CLOSE event. The HID subsystem performs +UHID_OPEN events without a UHID_CLOSE event. The HID subsystem performs ref-counting for you. You may decide to ignore UHID_OPEN/UHID_CLOSE, though. I/O is allowed even though the device may have no users. If you want to send data on the interrupt channel to the HID subsystem, you send -an HID_INPUT2 event with your raw data payload. If the kernel wants to send data -on the interrupt channel to the device, you will read an UHID_OUTPUT event. +a HID_INPUT2 event with your raw data payload. If the kernel wants to send data +on the interrupt channel to the device, you will read a UHID_OUTPUT event. Data requests on the control channel are currently limited to GET_REPORT and SET_REPORT (no other data reports on the control channel are defined so far). Those requests are always synchronous. That means, the kernel sends @@ -71,7 +71,7 @@ the response via UHID_GET_REPORT_REPLY a The kernel blocks internal driver-execution during such round-trips (times out after a hard-coded period). -If your device disconnects, you should send an UHID_DESTROY event. This will +If your device disconnects, you should send a UHID_DESTROY event. This will unregister the device. You can now send UHID_CREATE2 again to register a new device. If you close() the fd, the device is automatically unregistered and destroyed @@ -125,7 +125,7 @@ UHID_START: This is sent when the HID device is started. Consider this as an answer to UHID_CREATE2. This is always the first event that is sent. Note that this event might not be available immediately after write(UHID_CREATE2) returns. - Device drivers might required delayed setups. + Device drivers might require delayed setups. This event contains a payload of type uhid_start_req. The "dev_flags" field describes special behaviors of a device. The following flags are defined: @@ -149,7 +149,7 @@ UHID_STOP: reloaded/changed the device driver loaded on your HID device (or some other maintenance actions happened). - You can usually ignored any UHID_STOP events safely. + You can usually ignore any UHID_STOP events safely. UHID_OPEN: This is sent when the HID device is opened. That is, the data that the HID @@ -166,17 +166,17 @@ UHID_OUTPUT: This is sent if the HID device driver wants to send raw data to the I/O device on the interrupt channel. You should read the payload and forward it to the device. The payload is of type "struct uhid_output_req". - This may be received even though you haven't received UHID_OPEN, yet. + This may be received even though you haven't received UHID_OPEN yet. UHID_GET_REPORT: This event is sent if the kernel driver wants to perform a GET_REPORT request - on the control channeld as described in the HID specs. The report-type and + on the control channel as described in the HID specs. The report-type and report-number are available in the payload. The kernel serializes GET_REPORT requests so there will never be two in parallel. However, if you fail to respond with a UHID_GET_REPORT_REPLY, the request might silently time out. - Once you read a GET_REPORT request, you shall forward it to the hid device and - remember the "id" field in the payload. Once your hid device responds to the + Once you read a GET_REPORT request, you shall forward it to the HID device and + remember the "id" field in the payload. Once your HID device responds to the GET_REPORT (or if it fails), you must send a UHID_GET_REPORT_REPLY to the kernel with the exact same "id" as in the request. If the request already timed out, the kernel will ignore the response silently. The "id" field is @@ -184,7 +184,7 @@ UHID_GET_REPORT: UHID_SET_REPORT: This is the SET_REPORT equivalent of UHID_GET_REPORT. On receipt, you shall - send a SET_REPORT request to your hid device. Once it replies, you must tell + send a SET_REPORT request to your HID device. Once it replies, you must tell the kernel about it via UHID_SET_REPORT_REPLY. The same restrictions as for UHID_GET_REPORT apply.