Received: by 10.223.185.116 with SMTP id b49csp1016485wrg; Fri, 16 Feb 2018 10:52:44 -0800 (PST) X-Google-Smtp-Source: AH8x2270jN2jCWdVzX06WCwPId3j5VEKETfphHL1gFjQZCRrFwBu6eL9GY5sSqBW4RjRneC/mRv7 X-Received: by 10.99.172.66 with SMTP id z2mr5720300pgn.273.1518807163997; Fri, 16 Feb 2018 10:52:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518807163; cv=none; d=google.com; s=arc-20160816; b=CsTj5TzVYXYIQ+a5Jc8hgMqFZKviZksE3YPk4ifxlkdWs6nLVIUUZjTweAZ/Jl3KsF rDyJms+/ijjvFWTexjoIyx/Ar5t6ko3Er6OpiscBAvoukql6GnKPVFoyTNVCUJH18jR3 +BM4l42JDiSDDsto7V8HIBYKpv/SxK8BLBVFAnnKnydWtxo8FQdBr4udzVoV7JAJaiYZ 7blZgdZyBI1f1K3lcecDt58yiWjoFg+nd7MpI/ics17Mm/ifo5/KCI+6YRvWTOLOB2Zg sTLjY1WjGDyly9UD9hPA8XsKZDSXKDjzKCneOLctm0vNVoL9c8+cgIwpcetE3HorkpWY B2NQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=WInmbswozlt02aV20cT7ikcdqGaWDyDz5Qnc21jsBJ0=; b=sEb9F4JKRcRCbCPCroc83oIAS4VT5gX4Q3K8WhMew2JTA1MEE6uBXFZFZkljfXpwgH jBgbel8gpSpJZZTwEi/ITklV1v80GUBMwVDlQytpzpMgRWOmrJvyWPF/8jaikmQbujQU Fq24fv6zACcc8en5V9iBlDevF5v4vlGuHmXIplzSy+iK1Kl+Aq5MLs0jUiDmwS3lqYc2 vnQuTedbqFWM+4A6JNmpH9fvzmrYNWFITOqe8W11YObRmbmwBppV/ZhA1xKufjcXgc/4 ykxWnLEQD1gVjfBp+yDt4P+4bL9FRcDTvbmys+SiUQnw5IqrsnEZxcBxgcGahSGpuOhz +APA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=gboL4x7E; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o7si2809045pgs.314.2018.02.16.10.52.29; Fri, 16 Feb 2018 10:52:43 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=gboL4x7E; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757496AbeBPJCt (ORCPT + 99 others); Fri, 16 Feb 2018 04:02:49 -0500 Received: from mail-wr0-f173.google.com ([209.85.128.173]:45943 "EHLO mail-wr0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757485AbeBPJCr (ORCPT ); Fri, 16 Feb 2018 04:02:47 -0500 Received: by mail-wr0-f173.google.com with SMTP id p104so822486wrc.12; Fri, 16 Feb 2018 01:02:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=WInmbswozlt02aV20cT7ikcdqGaWDyDz5Qnc21jsBJ0=; b=gboL4x7EiJpC1q5KQgcd59epUIL4HSjwSFi2Kzpohg5MOjRL7eIn5RZqw2WNJRRpFR qlXNa9qWAb3i0TjvM82QGzTOATUSuwHEvX5O7JHUfuCRy7NGeEqMA/uu4+Bc7gRttY8O gPOkReOZjrXaiENiiX9LYaCRYEhoqISg5XjXCMz3QUndOfHoXScy3j2uWdAsTk8yun6O PVgMogk+iCV8+BW6CjQNV9Ppb5idUUpZu7b/rSljKc2Xg1veK4+quwuZ/5A2XuRx5s/s kmA7t5glLmerMPyhAPcpdSaL7Fr+O3jFeqJ9KZy4QswshiSh1rCaNLGG5qFKFwkwenoM Xgfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=WInmbswozlt02aV20cT7ikcdqGaWDyDz5Qnc21jsBJ0=; b=tL782RkdUUYCrinfIMfjOyLqaXgugbeXvCQLyfdvgn9RWn3isDkfSwJTuyGB+2iaTX kvQy7Sn8NfnIFqTV9c1Gvfl4hjByJHj8LlwMyhdhkjYazY/EL5MVi49IOiZi2s1Nggn7 PI2P3Azb86sCNYj+Fp/XWROtW7AIgMKUu1RLknyjTbkOrceP/iZUTV2G7jBzQs4hKzVd e8Pm5GUL45xuyGVIyDPFlKRQnT+yPLMRO/C9uyaP247VEeckgrxyFbm1M+RXxH40rPUw mDL1NfI1wpWnqSLEiJS+i/QUBF8NkOwsERuwhnzxyMjUe+5yBTaid2kKoiWHW7tCu6+M mOvg== X-Gm-Message-State: APf1xPCsavWm+s+oRzs9bFvRe+EJqxW5wx/uHYs8QSR0d3DpTJoAGQj+ j05Ok+OdkyFNfJ3ryySlSL0= X-Received: by 10.223.186.15 with SMTP id o15mr5362910wrg.101.1518771766226; Fri, 16 Feb 2018 01:02:46 -0800 (PST) Received: from casa ([2a01:c50e:5126:7a00:4dc5:23c5:d72:18]) by smtp.gmail.com with ESMTPSA id m86sm17592029wmi.40.2018.02.16.01.02.44 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 16 Feb 2018 01:02:45 -0800 (PST) Date: Fri, 16 Feb 2018 10:02:43 +0100 From: Rodrigo Rivas Costa To: Benjamin Tissoires Cc: Jiri Kosina , lkml , linux-input@vger.kernel.org Subject: Re: [PATCH 2/3] HID: steam: add serial number information. Message-ID: <20180216090243.GB18755@casa> References: <20180213120308.23879-1-rodrigorivascosta@gmail.com> <20180213120308.23879-2-rodrigorivascosta@gmail.com> <20180215221633.GA18755@casa> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.3 (2018-01-21) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Feb 16, 2018 at 09:44:34AM +0100, Benjamin Tissoires wrote: > > I have an issue with this one. The problem is that using > > hid_report_len() on the feature report returns 64. But I must call > > hid_hw_raw_request() with 65 or it will fail with EOVERFLOW. > > > > Currently I'm allocating a buffer of 65 bytes and all is well. > > If I change to hid_alloc_report_buf(), the current implementation > > allocates (64+7), so I'm still safe. But I'm worried that the extra > > bytes are not guaranteed and a future implementation could return > > exactly 64 bytes, leaving me 1 byte short. > > > > About why an array of 65 is required for a report of size 64, I think it > > is related to hid_report->id == 0 (so hid_report_enum->numbered == 0). > > That's the other way around actually. If you are just using the output > of hid_report_len(), it will take into account the extra byte for the > report ID. > *But*, given the way implement() is working (see the comment in the > implementation of hid_alloc_report()), you need to have up to 7 extra > bytes to not have the EOVERFLOW. > > So if we ever change the implement() function (which is *really* > unlikely), we will have to make sure hid_alloc_report() still works, > so you are on the safe side if you use hid_alloc_report(). Ok, I'll do that. The weird thing, however, is that: hid_hw_raw_request(steam->hid_dev, 0x00, buf, hid_report_len(r), /* 64 */ HID_FEATURE_REPORT, HID_REQ_GET_REPORT); fails with EOVERFLOW. I have to use: hid_hw_raw_request(steam->hid_dev, 0x00, buf, 65 HID_FEATURE_REPORT, HID_REQ_GET_REPORT); which just feels wrong to me. And looking around drivers/hid/*.c I see that most calls to hid_hw_raw_request(..., HID_REQ_GET_REPORT) use a buffer allocated with {devm_,}kzalloc() and a constant length, never using hid_alloc_report_buf() or hid_report_len(). Maybe there is a bug in hid_hw_raw_request() and it should add 1 to the given buffer len? But then, custom buffer allocations will overflow by one! Rodrigo.