linux-kernel - RE: [PATCH] Input: wdt87xx_i2c

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 6 Sep 2016 11:47:39 +0000
From:   Hn Chen <hn.chen@...dahitech.com>
To:     Benjamin Tissoires <benjamin.tissoires@...hat.com>
CC:     Dmitry Torokhov <dmitry.torokhov@...il.com>,
        "linux-input@...r.kernel.org" <linux-input@...r.kernel.org>,
        lkml <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] Input: wdt87xx_i2c - support new body WDT8752

Hi Benjamin,

Sorry for my poor English and leading you misunderstanding.

The FW of WDT8752 can support HIDI2C for Windows products. And then we develop this driver.
So we "borrowed" something from HIDI2C.
What I try to mention here is that this driver utilize a part of existed protocol from HIDI2C.
We thought that the size of FW can be shrunk in that way.

So, basically, this is still a linux i2c driver with some protocols similar to HIDI2C.

BR,
Hn.chen

-----Original Message-----
From: Benjamin Tissoires [mailto:benjamin.tissoires@...hat.com] 
Sent: Monday, September 05, 2016 9:56 PM
To: Hn Chen
Cc: Dmitry Torokhov; linux-input@...r.kernel.org; lkml
Subject: Re: [PATCH] Input: wdt87xx_i2c - support new body WDT8752

Hi HN,

On Sep 05 2016 or thereabouts, Hn Chen wrote:
> Hi Dmitry,
> 
> >> Considering to be compatible with i2c-hid, WDT8752 has the same way 
> >> in enumerating device.
> >If it is a HID device then I think you should write a HID driver for it (unless existing driver, such as hid-multitouch can already handle it, possibly >with some changes). I'm addng Benjamin to he can comment as well.
> The device can be handled by i2c-hid driver (HID over I2C) already but this proprietary driver still is a must-have for more features.

Then what are those must-have features? From what I can read, only the reflashing firmware is part of it. Unless there is something else, I really don't understand why you can't have a hid-weidatech driver that could handle the specific bits while leaving the rest to i2c-hid.

Also, I am not sure if your driver doesn't interfere with i2c-hid as you are claiming the device through the ACPI ID "WDHT0001" but there should be some PNP IDs "PNP0C50" if it were declared as i2c-hid. If both are set, then the fact your driver is picked up seems to be pure luck: there will be a race between the probe of your driver and i2c-hid, which is not something you want.

If there are some issues with i2c-hid, I'd like also to know them because if we fix them for you there  is a high chance other vendors will benefit from those fixes too.

Cheers,
Benjamin

> 
> >> And also modify the part of FW update to be more efficiency. The 
> >> main modification is that reducing the amount of data transmitted 
> >> and using polling for time comsuming operation.
> >>
> >> Flash erase will wait 50ms for the operation complete in last driver.
> >> Extend it to 200ms since the spec says the typical is 30ms but the 
> >> max is 200ms.
> >This should be split into a separate patch please.
> Ok, I will resubmit the part of possible-issue fixing and then the driver patch for supporting WDT8752 again.
> Please ignore this submission.
> 
> Hn.chen