Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp773529pxb; Tue, 5 Apr 2022 22:44:28 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxPwQDFr4K7Syhbt1t5ORhk5L2rMDd1PGWGurPTc2KwSzTJsUPc3bELvJ/o398IBW63SX3f X-Received: by 2002:aa7:8a4a:0:b0:4fa:e155:f03c with SMTP id n10-20020aa78a4a000000b004fae155f03cmr7283235pfa.67.1649223868320; Tue, 05 Apr 2022 22:44:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649223868; cv=none; d=google.com; s=arc-20160816; b=QAG027cAjBd7XGqa2ZWPfZ5xhWRCNbIfSuR3sJH/i8cV0V02+Ih2DTl6Utyq7EgGtL 1omv0fcZRhUEcXhFFSF5PfFu2L5Wdeo40OERk3p4bqk2hrO+N7DiQ0L7urVFnpV5ew4w 7efxaPMucZM1UsmNbYV//LQwuX8awpQDn82S8MwMwaUe8E5dI0T/1T5NZJi7RHKFDElO OsaSgMyvArhjt31v88YKvu26NN5UhuGuYIClYuRSoRoNv7BMebftRxPtXiKWv7prp0VE WhiU47RZwsFvnoDD4575mJNWVLcTpz3ChINWVnvhNXUXTGWYNOmOwcqsYZdV8wEndpYx wT2A== 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=KxYR2gjUJSspKWIf/uyhSqq2BUNBPeWNLTdWVlw8zF0=; b=ydLadE1/ISIDpM07gOFKqUJSL90n8sFP7u2mdp1RGSoOXGHLDfX1jN3aehTOHdgN5o koJAKcUN5iyVVKOt8l2/Lea21xnIsEm4/Wlr8EyxDp2l/GPw9MV/f9y323L+eHFGaQ5u qui2a8Dv+da3aw7Upc00xcGqZ7qum1M7bvH1hk66bNy0SAig73sYNndfOSzJ1124ySUY S4bVcp8awwNRqmRVeB5dE+SeigMlzwhoCAbIqP+kmTmkLTadEyeyrnCRA6aYDJkh2g9u RymgOn3fYpEou69WxgI/Pn/Smzr++9xEAvcEkcE14rc7VAge1Gr5omcPzyeO4FBZYzR0 yAsA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=AwU4FkAC; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 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 lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id h73-20020a62834c000000b004fa3a8e0023si13967774pfe.218.2022.04.05.22.44.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Apr 2022 22:44:28 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=AwU4FkAC; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 5D0DB467E3C; Tue, 5 Apr 2022 21:57:54 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1580099AbiDEXd4 (ORCPT + 99 others); Tue, 5 Apr 2022 19:33:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48994 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1349054AbiDEJtC (ORCPT ); Tue, 5 Apr 2022 05:49:02 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A296DA94E4; Tue, 5 Apr 2022 02:39:21 -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 ams.source.kernel.org (Postfix) with ESMTPS id 5192BB81C14; Tue, 5 Apr 2022 09:39:20 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9C97CC385A2; Tue, 5 Apr 2022 09:39:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1649151559; bh=o7C32F3i+PJr0RVLaJ/A++tomV2VND/4bsNJ7OCF4as=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=AwU4FkACMVkRBMc6gB9LI2v7p6xZnPCnfG7w4KRoWiq30S57/GfUO60gGvlk6/bNh ZoF5P6+/36HuNaPIYTQvYoIaBfnnyDcwEKzWVTMWTUuX1z1GeQJvEhNvTy9gZNdZse x1KzgkeZFRKzMYOIKhUySYczEnaUoW2MD7/l5TeA= 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 5.15 452/913] HID: i2c-hid: fix GET/SET_REPORT for unnumbered reports Date: Tue, 5 Apr 2022 09:25:14 +0200 Message-Id: <20220405070353.397482580@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220405070339.801210740@linuxfoundation.org> References: <20220405070339.801210740@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=-2.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no 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 4804d71e5293..65c1f20ec420 100644 --- a/drivers/hid/i2c-hid/i2c-hid-core.c +++ b/drivers/hid/i2c-hid/i2c-hid-core.c @@ -615,6 +615,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); @@ -636,6 +647,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; } @@ -652,17 +666,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