linux-kernel - Re: [PATCH 2/5] Input: add driver for Focaltech FTS touchscreen

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: <0f6e0854-5097-3abe-8e02-36cb7027bf61@gmail.com>
Date:   Sun, 9 Apr 2023 09:24:10 -0500
From:   Joel Selvaraj <joelselvaraj.oss@...il.com>
To:     Markuss Broks <markuss.broks@...il.com>,
        Caleb Connolly <caleb@...nolly.tech>,
        Dmitry Torokhov <dmitry.torokhov@...il.com>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Andy Gross <agross@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio <konrad.dybcio@...aro.org>,
        Henrik Rydberg <rydberg@...math.org>,
        Arnd Bergmann <arnd@...db.de>,
        Robert Jarzmik <robert.jarzmik@...e.fr>,
        Jeff LaBundy <jeff@...undy.com>,
        Neil Armstrong <neil.armstrong@...aro.org>,
        Jean Delvare <jdelvare@...e.de>,
        Max Krummenacher <max.krummenacher@...adex.com>,
        Job Noorman <job@...rman.info>,
        Alistair Francis <alistair@...stair23.me>,
        Chris Morgan <macromorgan@...mail.com>
Cc:     linux-input@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org,
        ~postmarketos/upstreaming@...ts.sr.ht, phone-devel@...r.kernel.org
Subject: Re: [PATCH 2/5] Input: add driver for Focaltech FTS touchscreen

Hi Markuss,

On 09/04/23 08:32, Markuss Broks wrote:
> By that I meant doing something like the Zinitix driver[1] does. It has
> a struct data type for whatever you read from hardware, e.g.
> 
> struct point_coord {
>     __le16    x;
>     __le16    y;
> ...
> };
> 
> from that driver. That way you can cast the data read to that struct and
> have it look a bit nicer.

Understood. Thanks for the clarification. Jeff LaBundy explained it a
bit too. I have addressed all the other comments in this patch series in
my WIP v2. However, I am having quite the trouble casting the buffer to
a struct. The register layout is bit weird. It would have been easier if
they are sets of 8bits or 16bits values. Instead it seems to be split in
terms 4bits and 12bits or I don't know. I am a bit new to this and
having trouble handling endianess with these weird splits in the buffer.

Here is a hand drawn image of the buffer layout [1]. Let me know if you
or anyone have any thoughts on this. Wonder if it's worth the trouble :)

[1] https://imgur.com/a/4RYrB1G

> This is just a suggestion though, you have the final choice in what
> design you choose for your code :)

I am gonna try it a few more days and if I can't make it work in a
sensible way, I will probably go with the existing approach.

> - Markuss

Thanks,
Joel