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 for Android: free password hash cracker in your pocket

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

Message-ID: <20191211032813.GA17731@qmqm.qmqm.pl>
Date:   Wed, 11 Dec 2019 04:28:13 +0100
From:   Michał Mirosław <mirq-linux@...e.qmqm.pl>
To:     Dmitry Osipenko <digetx@...il.com>
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

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. :-)

Best Regards,
Michał Mirosław