Received: by 2002:a05:6a10:6d10:0:0:0:0 with SMTP id gq16csp3414772pxb; Tue, 19 Apr 2022 01:48:54 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxVoQTbl2rGZMafJ3AwZpPBoP+VGDqvF6sJ5U0rfsA66pl8bDmh2QMTZPfC/n8x4kCGTbsV X-Received: by 2002:a63:6849:0:b0:398:a546:1c46 with SMTP id d70-20020a636849000000b00398a5461c46mr13553860pgc.100.1650358134060; Tue, 19 Apr 2022 01:48:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1650358134; cv=none; d=google.com; s=arc-20160816; b=BY4efWJgR8k10ypUpsihGRe4t1mLMFs2FZnwkYKtnTTs6fM9TYaM10KLYa5/C9aJnj 3zqmFlMLljs4l3ZFs/1OA7MNNXwTrqvMayYKy3++jxvBVCV9v1geGQMu6CCRGa8ITs31 3bFu/PiGwrrGTtP2egu5MlBcnxzNm75mtrStTjic7dVsbe+1skUYG7O4wL6g6bxmeJXW yquXPJMNdZO3EGYzitG/IKFzh7XaNetdFB95Blv7TB3MECETGHxrfYHHUcTl3fIw9N8n QVDjxo+9ecoZMLrc5Xnw0kR1kncLNUXbkuN3tlNCfiMQ2XIX3NfxFgdypvGb7vU5dOML +AVw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=tCgRfczShsODQBzWBBk16Zc2Z3NDv972MFSN0++AMd4=; b=OR7VELkpxqyn75ZSqrvBDw42QZx/k+sE+ZkEO/1Uz8rV2EIZhoPjkvGTAjQwyhAtLx vVegP1/Q1wpkd0s9QpkeJdPDCInEiWOGKpmXFcVnoeqANrJDUb5Sp6WarhN+Iajj/cgz uVXuRnWCxRLJbDKN2IGcWSRLVk6HxDG47drqPBX3zBgAWFwNyFfbmZ4HvYUTPtG/8Pv2 Fz1eVyK5RLKLg624H94Kz4N5LWutGLsJZf2KU1++S1ACOKir4Has+tP6RapHOtKJkhbP DtJ8Q+G2YP15ArqVX/zVtvIWRDdvvALL/eOs0KZAx4w2oTp4/FZZgco4CcG+yecNPY9U 9Cuw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=HgmdGY34; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id y35-20020a631823000000b003aa493aa8c0si123102pgl.286.2022.04.19.01.48.38; Tue, 19 Apr 2022 01:48:54 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=HgmdGY34; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345375AbiDROTF (ORCPT + 99 others); Mon, 18 Apr 2022 10:19:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57218 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244628AbiDRN73 (ORCPT ); Mon, 18 Apr 2022 09:59:29 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 44C222B26E; Mon, 18 Apr 2022 06:08:41 -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 4986860F5D; Mon, 18 Apr 2022 13:08:22 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 26DE0C385A7; Mon, 18 Apr 2022 13:08:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1650287301; bh=um47YWGyCqvH9FgQD9icRJ5irpy90iVAj61xMwEcStQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=HgmdGY34AvjJXlsS2vsh4JkeazcP4cph5Wwn3PUUYPrDhd1E9+ms25VWcNlN8APpT 6hMUWX8l8gAdanlJIu3lESqhQGygG6lYDOfagHhndD37vesPwKQBnaaWbJkjxGFjsm 5dxoXidkjTlERppuxoOUwtUgt1YPqBgDBDZBmGRw= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Dmitry Torokhov , Benjamin Tissoires , Jiri Kosina , Sasha Levin Subject: [PATCH 4.9 082/218] HID: i2c-hid: fix GET/SET_REPORT for unnumbered reports Date: Mon, 18 Apr 2022 14:12:28 +0200 Message-Id: <20220418121201.952066075@linuxfoundation.org> X-Mailer: git-send-email 2.35.3 In-Reply-To: <20220418121158.636999985@linuxfoundation.org> References: <20220418121158.636999985@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Dmitry Torokhov [ Upstream commit a5e5e03e94764148a01757b2fa4737d3445c13a6 ] Internally kernel prepends all report buffers, for both numbered and unnumbered reports, with report ID, therefore to properly handle unnumbered reports we should prepend it ourselves. For the same reason we should skip the first byte of the buffer when calling i2c_hid_set_or_send_report() which then will take care of properly formatting the transfer buffer based on its separate report ID argument along with report payload. [jkosina@suse.cz: finalize trimmed sentence in changelog as spotted by Benjamin] Fixes: 9b5a9ae88573 ("HID: i2c-hid: implement ll_driver transport-layer callbacks") Signed-off-by: Dmitry Torokhov Tested-by: Benjamin Tissoires Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin --- drivers/hid/i2c-hid/i2c-hid-core.c | 32 ++++++++++++++++++++++-------- 1 file changed, 24 insertions(+), 8 deletions(-) diff --git a/drivers/hid/i2c-hid/i2c-hid-core.c b/drivers/hid/i2c-hid/i2c-hid-core.c index 518ccf15188e..26c7701fb188 100644 --- a/drivers/hid/i2c-hid/i2c-hid-core.c +++ b/drivers/hid/i2c-hid/i2c-hid-core.c @@ -643,6 +643,17 @@ static int i2c_hid_get_raw_report(struct hid_device *hid, if (report_type == HID_OUTPUT_REPORT) return -EINVAL; + /* + * In case of unnumbered reports the response from the device will + * not have the report ID that the upper layers expect, so we need + * to stash it the buffer ourselves and adjust the data size. + */ + if (!report_number) { + buf[0] = 0; + buf++; + count--; + } + /* +2 bytes to include the size of the reply in the query buffer */ ask_count = min(count + 2, (size_t)ihid->bufsize); @@ -664,6 +675,9 @@ static int i2c_hid_get_raw_report(struct hid_device *hid, count = min(count, ret_count - 2); memcpy(buf, ihid->rawbuf + 2, count); + if (!report_number) + count++; + return count; } @@ -680,17 +694,19 @@ static int i2c_hid_output_raw_report(struct hid_device *hid, __u8 *buf, mutex_lock(&ihid->reset_lock); - if (report_id) { - buf++; - count--; - } - + /* + * Note that both numbered and unnumbered reports passed here + * are supposed to have report ID stored in the 1st byte of the + * buffer, so we strip it off unconditionally before passing payload + * to i2c_hid_set_or_send_report which takes care of encoding + * everything properly. + */ ret = i2c_hid_set_or_send_report(client, report_type == HID_FEATURE_REPORT ? 0x03 : 0x02, - report_id, buf, count, use_data); + report_id, buf + 1, count - 1, use_data); - if (report_id && ret >= 0) - ret++; /* add report_id to the number of transfered bytes */ + if (ret >= 0) + ret++; /* add report_id to the number of transferred bytes */ mutex_unlock(&ihid->reset_lock); -- 2.34.1