linux-kernel - Re: [PATCH 3/6] input: elants: support common touchscreen DT properties

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] [day] [month] [year] [list]

Message-ID: <21532a63-6706-c082-5ab1-cf083bd3af47@gmail.com>
Date:   Wed, 11 Dec 2019 18:26:02 +0300
From:   Dmitry Osipenko <digetx@...il.com>
To:     Michał Mirosław <mirq-linux@...e.qmqm.pl>
Cc:     linux-input@...r.kernel.org,
        Dmitry Torokhov <dmitry.torokhov@...il.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/6] input: elants: support common touchscreen DT
 properties

11.12.2019 06:28, Michał Mirosław пишет:
> On Tue, Dec 10, 2019 at 06:21:02PM +0300, Dmitry Osipenko wrote:
>> 10.12.2019 05:38, Michał Mirosław пишет:
>>> On Tue, Dec 10, 2019 at 04:03:18AM +0300, Dmitry Osipenko wrote:
>>>> 10.12.2019 03:19, Michał Mirosław пишет:
>>>>> Support common DT properties like axis inversions to complement
>>>>> information obtained from device's firmware.a
>>> [...]
>>>>> @@ -1251,13 +1250,15 @@ static int elants_i2c_probe(struct i2c_client *client,
>>>>>  	ts->input->name = "Elan Touchscreen";
>>>>>  	ts->input->id.bustype = BUS_I2C;
>>>>>  
>>>>> +	touchscreen_parse_properties(ts->input, true, &ts->prop);
>>>>
>>>> Shouldn't this function be invoked after setting the max x/y sizes with
>>>> the hardware values? That's what all other drivers do and then you won't
>>>> need to set the ts->prop.max_x/y above in the code.
>>>
>>> This is done later in the series - this patch only adds axis inversion
>>> support and ignores DT-provided sizes.
>>
>> What is the reason of splitting it into two patches?
>>
>> Perhaps I'm still missing something, but why something a bit more simple
>> like this wouldn't yield exactly the same result:
> [...]
> 
> Originally I thought to skip probing the hardware when all info is
> already provided in devicetree. This didn't happen, though. I'll take
> your patch then, with a slight adjustment in "prop"'s position... And
> the rest of them, so as to not duplicate the work. :-)

Okay