Received: by 10.223.185.116 with SMTP id b49csp1015410wrg; Fri, 16 Feb 2018 10:51:27 -0800 (PST) X-Google-Smtp-Source: AH8x2269iCrY/fEV4qV03gHjReWEV1D8Sog1dP1f4wBzzcYk90aGnIT+oq5Pk5vGPjkl1gVtqAba X-Received: by 10.99.1.70 with SMTP id 67mr5969983pgb.23.1518807087378; Fri, 16 Feb 2018 10:51:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518807087; cv=none; d=google.com; s=arc-20160816; b=lQIXCLJeobsdLHkSNlkS6hNrw2pZtw6YoKKnlxCvIB95ehXqMtjq1Bim7XrNXWenPb la80cuS9JX/y7SYZTQ7BkV08g4yEBqUKUh/nkNtnRZy2NS7tehSliWj33JDuhKR0VEkZ eChrqLG5DQWpFKd06DhAnxFLi8gToE7S45K2rEvdXBOMTXO2m0wn62UpFaphL1i6hJdX RcT3OSC2TikvM+K56Idu38wu5yZGLiU7u2Uiv9rwg7yEKSqTviuS30sDDbGe6kNlCXzb uwGtl/DjBhlSA7uLR55CaqO80qx6LQlkAbtzEZUkykcVKRo7DRtHZW2iYnv98Xd0YhyL LkHw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:arc-authentication-results; bh=rUw1XYXGX8LJalkosev8JNwLDWEEjPWjVkvCdYfRSWA=; b=AirXKkB709h5cayC/NMTlnIC/kM3H/phR6jiDEi7eiqau5PiLaz7hDQwrJMdw/Kbk9 qmd+YIIYinCeqrl5LbmXsRo3GplkG4Pi4UXHgekR4spfye/4DBiuHPgY5WiqJXRoI7Yy xVuPKrmmFg9APe5xSItMZCCrp1i8ZY5NFbj17Ov1nEkxNKs0xapbxNv+nIBJbz7bUwAY +bOqtrIBDPmDr3lUX4Dw5SAri+c+ZUeIIbDgIg3qeXOLXu82mSWEGfM9zM/pidFsWd3T jEXHguxlA1WeAgeRUdmeyPvU24fqVXrjPcZlYQeVH3yMxo32PqjRaZCBRKx96HCtjA0Y 4iPw== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 1-v6si6395157ple.726.2018.02.16.10.51.13; Fri, 16 Feb 2018 10:51:27 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754964AbeBPIoh (ORCPT + 99 others); Fri, 16 Feb 2018 03:44:37 -0500 Received: from mail-qk0-f169.google.com ([209.85.220.169]:41385 "EHLO mail-qk0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754869AbeBPIof (ORCPT ); Fri, 16 Feb 2018 03:44:35 -0500 Received: by mail-qk0-f169.google.com with SMTP id h129so2883356qke.8 for ; Fri, 16 Feb 2018 00:44:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rUw1XYXGX8LJalkosev8JNwLDWEEjPWjVkvCdYfRSWA=; b=lpmtxybflbQanSM0K4GZfMFPkmY+eZdHlZeF4HObQL+w+WWVquBbJLEevKnSha4qr6 YijJ4WCc7hOmN5Gjv46YhdT6wU3yJi0y3RaHu+fcDNXf1k6ykkJB28w4J8qrxp0wPdYa WwROzGzaZjfgg1Dn9XErgck9cFaT1eI5E4O33YWneBUnI7hBV5TpuTLBdWpIrDVvFebf 4biCP5A+ANcd5Vb4b92lH3oCmt67YiyBbj+lDcvsOixSYlGtY0S4ZHFzlEaB5fN/qcYV L/wCDRAWEX1y6SyQvib+LoTBJ8afOdqQx6q7+38ddYqZbh5BJZBWEpxRtHWVZOoLtURh DGDQ== X-Gm-Message-State: APf1xPAYXG+awS5vsF6pUFyxqqQ/pKf7hFZeDrl6Wat8u0WynDt2ZEYp JUJ9SNplJrLl++KCktjxlMGaX8Yus+eliNtJJkPCMg== X-Received: by 10.55.97.66 with SMTP id v63mr8197140qkb.266.1518770674644; Fri, 16 Feb 2018 00:44:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.26.166 with HTTP; Fri, 16 Feb 2018 00:44:34 -0800 (PST) In-Reply-To: <20180215221633.GA18755@casa> References: <20180213120308.23879-1-rodrigorivascosta@gmail.com> <20180213120308.23879-2-rodrigorivascosta@gmail.com> <20180215221633.GA18755@casa> From: Benjamin Tissoires Date: Fri, 16 Feb 2018 09:44:34 +0100 Message-ID: Subject: Re: [PATCH 2/3] HID: steam: add serial number information. To: Rodrigo Rivas Costa Cc: Jiri Kosina , lkml , linux-input@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Feb 15, 2018 at 11:16 PM, Rodrigo Rivas Costa wrote: > On Wed, Feb 14, 2018 at 03:51:31PM +0100, Benjamin Tissoires wrote: >> On Tue, Feb 13, 2018 at 1:03 PM, Rodrigo Rivas Costa >> > +#define STEAM_FEATURE_REPORT_SIZE 65 >> > + >> > +static int steam_send_report(struct steam_device *steam, >> > + u8 *cmd, int size) >> > +{ >> > + int retry; >> > + int ret; >> > + u8 *buf = kzalloc(STEAM_FEATURE_REPORT_SIZE, GFP_KERNEL); >> >> Please use hid_alloc_report_buf() as sometimes we need to allocate a >> slightly bigger report. > > 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(). > > So what would be the proper solution? hid_alloc_report() is the one you want :) And generally speaking, using the internal API to deal with reports and others is the safe bet, as you are guaranteed to not being broken if the API changes (or it'll be a regression and we will have to take this as high priority). Cheers, Benjamin > > Thanks. > Rodrigo.