Received: by 2002:a25:824b:0:0:0:0:0 with SMTP id d11csp1895822ybn; Thu, 26 Sep 2019 03:58:39 -0700 (PDT) X-Google-Smtp-Source: APXvYqw7fBccNClOavLKsbAckDpglEfwdGqTmyKn+utVkEeA7PIFZjnMD7Ao2wmer5mv17JJvI7q X-Received: by 2002:a50:d808:: with SMTP id o8mr2873703edj.74.1569495519425; Thu, 26 Sep 2019 03:58:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1569495519; cv=none; d=google.com; s=arc-20160816; b=VhL5S8UphGPU8bJxfQPQbGgYbGdzitb6rcysP8JjP401kkIhM8YOtp12ZqI9f+vFyi 8vaP7R1mogv9+hoJSzDe6gZFd41u1SRn0x8nO0KJAb5UXy3yiH8Cbp7N1efTbTelV7qJ V8O3qJliP/ZlgjelOu0HTIf0uNG3aveTgSam8+e7ck+3/a4pONBZcqDijrxqj0Q5bIK7 9nENNksYSq9R2z/9c9rhlIpikGRQ74btNcSWL7aywDJ3qRvbUwnTaz7CQT40bnKFdDp/ 5dwiYg/LyLO5+mu7Q3OscpBJklFTxU6GehAWWVjmAHdBbDKI9ULSy+wJI6zouyF626CI fJEA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=4oywSfuMp7J3ZB2f2owykN0tPRscErPawez4SzM22Ns=; b=YRAu2r6LEsE+xfOtygSSNQduwPax6U7l/fzzspDFNfYsLhoS/zPM70NOQXDbc30MaA HII339ESeT/iQI0ELklmjAKUYXUnXDmx8zLGzy4znS0YqFLLWQZFzvZ2Z1v/LPmnhE14 2JDWplqEfXFzjbLt1KpZstLHSlttfSOgBFqt24iZtgJhyc+7Mb+T9hK58+K66GhZezhE TXX048n4pyK30Jbx5loMWCTJhPoqzCzZ+JDlPxKKZY3J1Lh0I9yOfBktxKozz+wt0cvM Rl9DaCw7RkKVohpvQacSyY4rb31muBEUm9KuoG5qQPnypls7VMyNQGXA0jNcNe3zGWDX GCJA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b="jGKB7/Bs"; 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=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 e50si1236136edb.177.2019.09.26.03.58.15; Thu, 26 Sep 2019 03:58:39 -0700 (PDT) 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=@redhat.com header.s=mimecast20190719 header.b="jGKB7/Bs"; 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=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726429AbfIZK3n (ORCPT + 99 others); Thu, 26 Sep 2019 06:29:43 -0400 Received: from us-smtp-1.mimecast.com ([207.211.31.81]:28773 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725787AbfIZK3m (ORCPT ); Thu, 26 Sep 2019 06:29:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1569493781; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=4oywSfuMp7J3ZB2f2owykN0tPRscErPawez4SzM22Ns=; b=jGKB7/BsVrDga4dlSolLZZ8dMMKcM3fFGBNaRWEEoUcGAVKxIvlleMzt+mMyFGkWsPx6Ba kKvqM6r4v2UNI4lTYsvQgHXFwVmPU+kvefswaZwnxl9dIUg8d4lrr7XHgGAvCDXmRvCnPa KPubikpQilpBygsXbGAfh8+2TkYsJzA= Received: from mail-qt1-f198.google.com (mail-qt1-f198.google.com [209.85.160.198]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-233-OUUqLTxmPu6eSG1TGVSgPw-1; Thu, 26 Sep 2019 06:29:40 -0400 Received: by mail-qt1-f198.google.com with SMTP id f15so1857418qth.6 for ; Thu, 26 Sep 2019 03:29:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=moofdL//faBtrlG0QLSwcgJuXbtQtXBYxvEroylMNe4=; b=NBlFSepXQ3kRScdW69Hatk7P6k+RxzDEmvPr4IPnq6NQgVNqau+C7a91E+95FXNxL/ GvA71vB+/LMlmBcDZRa23sGYpk2xZCcuHuUkyEgvUhl8pgqHsvbR1eeYe6przod3brMM 7Pe7Ed7ar6e/P5rvt8U4QFQXdhKoqRods9us1Xid9ez9PmQlUS0wlftMzYSvb4NKqShc dpYS7A1jCRjtc8IKc8QaXY8QpE3InwWeEhdO19A+aj4Nhr4fRws1ECL7ZT08hpu6aWDK 6x3Q6UQnsLzORcxKcDEhfMH1UyMdeErDpHlcUFy2Ru5n48Mv+9zjLfKTIMf+gYfnkLid DhPw== X-Gm-Message-State: APjAAAVKH/gYEs1MVUc9juuwAGAlPiNfGIlzbCTklm6B2ivZTzAeYIZP lqk8ldSdcbwQZLL6s6X1DYLLjA+Zup+MuNrqHFub+oAVesqFc99K+gcEpPGxICYQmpXLC7fcUoS 9qdCjX7lgd968E5NSvD0QLkHeXYB/zXuJ92K94xue X-Received: by 2002:ac8:3059:: with SMTP id g25mr3075843qte.154.1569493779596; Thu, 26 Sep 2019 03:29:39 -0700 (PDT) X-Received: by 2002:ac8:3059:: with SMTP id g25mr3075822qte.154.1569493779304; Thu, 26 Sep 2019 03:29:39 -0700 (PDT) MIME-Version: 1.0 References: <20190925094326.41693-1-vicamo.yang@canonical.com> <20190925094326.41693-2-vicamo.yang@canonical.com> In-Reply-To: <20190925094326.41693-2-vicamo.yang@canonical.com> From: Benjamin Tissoires Date: Thu, 26 Sep 2019 12:29:27 +0200 Message-ID: Subject: Re: [PATCH 1/2] HID: i2c-hid: allow delay after SET_POWER To: You-Sheng Yang Cc: Dmitry Torokhov , Rob Herring , Mark Rutland , Jiri Kosina , Kai-Heng Feng , Hui Wang , Julian Sax , HungNien Chen , "open list:HID CORE LAYER" , DTML , lkml X-MC-Unique: OUUqLTxmPu6eSG1TGVSgPw-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On Wed, Sep 25, 2019 at 11:43 AM You-Sheng Yang wrote: > > According to HID over I2C specification v1.0 section 7.2.8, a device is > allowed to take at most 1 second to make the transition to the specified > power state. On some touchpad devices implements Microsoft Precision > Touchpad, it may fail to execute following set PTP mode command without > the delay and leaves the device in an unsupported Mouse mode. > > This change adds a post-setpower-delay-ms device property that allows > specifying the delay after a SET_POWER command is issued. I must confess I have at least 2 problems with your series: - this patch is quite hard to review. There are unrelated changes and it should be split in at least 2 (I'll detail this in the code review below) - you are basically adding a new quirk when Windows doesn't need it. So before we merge this, I'd like to actually know if Windows is doing the same and if we could not mimic what Windows is doing to prevent further similar quirks in the future. > > References: https://bugzilla.kernel.org/show_bug.cgi?id=3D204991 > Signed-off-by: You-Sheng Yang > --- > .../bindings/input/hid-over-i2c.txt | 2 + > drivers/hid/i2c-hid/i2c-hid-core.c | 46 +++++++++++-------- > include/linux/platform_data/i2c-hid.h | 3 ++ > 3 files changed, 32 insertions(+), 19 deletions(-) > > diff --git a/Documentation/devicetree/bindings/input/hid-over-i2c.txt b/D= ocumentation/devicetree/bindings/input/hid-over-i2c.txt > index c76bafaf98d2f..d82faae335da0 100644 > --- a/Documentation/devicetree/bindings/input/hid-over-i2c.txt > +++ b/Documentation/devicetree/bindings/input/hid-over-i2c.txt > @@ -32,6 +32,8 @@ device-specific compatible properties, which should be = used in addition to the > - vdd-supply: phandle of the regulator that provides the supply voltage. > - post-power-on-delay-ms: time required by the device after enabling its= regulators Why are you removing those 2 properties? > or powering it on, before it is ready for communication. > +- post-setpower-delay-ms: time required by the device after a SET_POWER = command > + before it finished the state transition. couple of issues: - the name might not be the best. It is similar to the post-power-on-delay while having a complete different impact. (note: I don't have a better name at hand) - checkpatch complains that device tree changes should be in a separate patch, and I tend to agree. > > Example: > > diff --git a/drivers/hid/i2c-hid/i2c-hid-core.c b/drivers/hid/i2c-hid/i2c= -hid-core.c > index 2a7c6e33bb1c4..a5bc2786dc440 100644 > --- a/drivers/hid/i2c-hid/i2c-hid-core.c > +++ b/drivers/hid/i2c-hid/i2c-hid-core.c > @@ -168,6 +168,7 @@ static const struct i2c_hid_quirks { > __u16 idVendor; > __u16 idProduct; > __u32 quirks; > + __u32 post_setpower_delay_ms; > } i2c_hid_quirks[] =3D { > { USB_VENDOR_ID_WEIDA, HID_ANY_ID, > I2C_HID_QUIRK_SET_PWR_WAKEUP_DEV }, > @@ -189,21 +190,20 @@ static const struct i2c_hid_quirks { > * i2c_hid_lookup_quirk: return any quirks associated with a I2C HID dev= ice > * @idVendor: the 16-bit vendor ID > * @idProduct: the 16-bit product ID > - * > - * Returns: a u32 quirks value. > */ > -static u32 i2c_hid_lookup_quirk(const u16 idVendor, const u16 idProduct) > +static void i2c_hid_set_quirk(struct i2c_hid *ihid, > + const u16 idVendor, const u16 idProduct) > { > - u32 quirks =3D 0; > int n; > > for (n =3D 0; i2c_hid_quirks[n].idVendor; n++) > if (i2c_hid_quirks[n].idVendor =3D=3D idVendor && > (i2c_hid_quirks[n].idProduct =3D=3D (__u16)HID_ANY_ID= || > - i2c_hid_quirks[n].idProduct =3D=3D idProduct)) > - quirks =3D i2c_hid_quirks[n].quirks; > - > - return quirks; > + i2c_hid_quirks[n].idProduct =3D=3D idProduct)) { > + ihid->quirks =3D i2c_hid_quirks[n].quirks; > + ihid->pdata.post_setpower_delay_ms =3D > + i2c_hid_quirks[n].post_setpower_delay_ms; > + } Why are you changing the signature of i2c_hid_set_quirk? If this is really a good thing to do, it should go in a separate patch. > } > > static int __i2c_hid_command(struct i2c_client *client, > @@ -431,8 +431,22 @@ static int i2c_hid_set_power(struct i2c_client *clie= nt, int power_state) > power_state =3D=3D I2C_HID_PWR_SLEEP) > ihid->sleep_delay =3D jiffies + msecs_to_jiffies(20); > > - if (ret) > + if (ret) { > dev_err(&client->dev, "failed to change power setting.\n"= ); > + goto set_pwr_exit; > + } > + > + /* > + * The HID over I2C specification states that if a DEVICE needs t= ime > + * after the PWR_ON request, it should utilise CLOCK stretching. > + * However, it has been observered that the Windows driver provid= es a > + * 1ms sleep between the PWR_ON and RESET requests and that some = devices > + * rely on this. > + */ > + if (ihid->pdata.post_setpower_delay_ms) > + msleep(ihid->pdata.post_setpower_delay_ms); > + else > + usleep_range(1000, 5000); Moving up this part needs definitively to be in a separate patch as well, with a good explanation on why. Cheers, Benjamin > > set_pwr_exit: > return ret; > @@ -456,15 +470,6 @@ static int i2c_hid_hwreset(struct i2c_client *client= ) > if (ret) > goto out_unlock; > > - /* > - * The HID over I2C specification states that if a DEVICE needs t= ime > - * after the PWR_ON request, it should utilise CLOCK stretching. > - * However, it has been observered that the Windows driver provid= es a > - * 1ms sleep between the PWR_ON and RESET requests and that some = devices > - * rely on this. > - */ > - usleep_range(1000, 5000); > - > i2c_hid_dbg(ihid, "resetting...\n"); > > ret =3D i2c_hid_command(client, &hid_reset_cmd, NULL, 0); > @@ -1023,6 +1028,9 @@ static void i2c_hid_fwnode_probe(struct i2c_client = *client, > if (!device_property_read_u32(&client->dev, "post-power-on-delay-= ms", > &val)) > pdata->post_power_delay_ms =3D val; > + if (!device_property_read_u32(&client->dev, "post-setpower-delay-= ms", > + &val)) > + pdata->post_setpower_delay_ms =3D val; > } > > static int i2c_hid_probe(struct i2c_client *client, > @@ -1145,7 +1153,7 @@ static int i2c_hid_probe(struct i2c_client *client, > client->name, hid->vendor, hid->product); > strlcpy(hid->phys, dev_name(&client->dev), sizeof(hid->phys)); > > - ihid->quirks =3D i2c_hid_lookup_quirk(hid->vendor, hid->product); > + i2c_hid_set_quirk(ihid, hid->vendor, hid->product); > > ret =3D hid_add_device(hid); > if (ret) { > diff --git a/include/linux/platform_data/i2c-hid.h b/include/linux/platfo= rm_data/i2c-hid.h > index c628bb5e10610..71682f2ad8a53 100644 > --- a/include/linux/platform_data/i2c-hid.h > +++ b/include/linux/platform_data/i2c-hid.h > @@ -20,6 +20,8 @@ > * @hid_descriptor_address: i2c register where the HID descriptor is sto= red. > * @supplies: regulators for powering on the device. > * @post_power_delay_ms: delay after powering on before device is usable= . > + * @post_setpower_delay_ms: delay after SET_POWER command before device > + * completes state transition. > * > * Note that it is the responsibility of the platform driver (or the acp= i 5.0 > * driver, or the flattened device tree) to setup the irq related to the= gpio in > @@ -36,6 +38,7 @@ struct i2c_hid_platform_data { > u16 hid_descriptor_address; > struct regulator_bulk_data supplies[2]; > int post_power_delay_ms; > + int post_setpower_delay_ms; > }; > > #endif /* __LINUX_I2C_HID_H */ > -- > 2.23.0 >