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: <CAD=FV=VphXewyk_mpGHUZKw8_aK8HnH8T-YumwM70eyz22S+Aw@mail.gmail.com>
Date: Mon, 21 Oct 2024 08:37:32 -0700
From: Doug Anderson <dianders@...omium.org>
To: Krzysztof Kozlowski <krzk@...nel.org>
Cc: Charles Wang <charles.goodix@...il.com>, dmitry.torokhov@...il.com, 
	hbarnor@...omium.org, conor.dooley@...rochip.com, jikos@...nel.org, 
	bentiss@...nel.org, linux-input@...r.kernel.org, devicetree@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] dt-bindings: input: Goodix SPI HID Touchscreen

Hi,

On Mon, Oct 21, 2024 at 2:43 AM Krzysztof Kozlowski <krzk@...nel.org> wrote:
>
> On 19/10/2024 04:55, Charles Wang wrote:
> > Hi Doug
> >
> > On Fri, Oct 18, 2024 at 01:48:56PM -0700, Doug Anderson wrote:
> >>
> >> On Thu, Oct 17, 2024 at 7:09 PM Charles Wang <charles.goodix@...il.com> wrote:
> >>>
> >>> The Goodix GT7986U touch controller report touch data according to the
> >>> HID protocol through the SPI bus. However, it is incompatible with
> >>> Microsoft's HID-over-SPI protocol.
> >>>
> >>> Signed-off-by: Charles Wang <charles.goodix@...il.com>
> >>> ---
> >>>  .../bindings/input/goodix,gt7375p.yaml        | 68 ++++++++++++++++---
> >>>  1 file changed, 58 insertions(+), 10 deletions(-)
> >>
> >> I'm happy to let device tree folks make the call here, but IMO it
> >> would be much cleaner to just consider the I2C-connected GT7986U and
> >> the SPI-connected GT7986U to be different things and just use a
>
> Same device, you cannot have different compatibles. The way how the same
> (literally same chip) device sits on the bus is not part of the binding,
> thus no different compatibles.

I don't want to belabour the point too much, but this doesn't feel
completely black and white here.

"Same chip": a whole lot of laptops and phones all use the "same chip"
(same SoC) yet are different products. ...or you can look at the fact
that many peripherals have the same STM32 or Nuvoton chip in them but
are wildly different peripherals.

In this case, Goodix may have made an ASIC called "GT7986U" that has
some type of CPU on it that can run firmware that can talk as an I2C
device or a SPI device. This ASIC may be intended to be used as a
touchscreen controller, but fundamentally it doesn't feel that
different from an STM32. You can build different boards designs with
the "GT7986U" on it and those boards are intended to run different
firmware.

People manufacturing touch controller boards presumably put this
"GT7986U" on their touch controller board, maybe set certain
strappings telling it that it's talking over SPI or I2C or maybe just
decide which pins they're going to wire out to the board-to-board
connector on the touch controller board. A touch controller board
intended to talk over SPI may look 98% the same as a touch controller
board intended to talk over I2C, but what percentage of "sameness"
means that we need the same compatible string?

Would things be different if Goodix decided to manufacture touch
controller boards themselves and sold two SKUs: a GT7986U-S and a
GT7986U-I?

I would also note that (reading back in previous conversations) I
think Charles said that they run different firmware on the SPI vs. I2C
touch controllers. As I understand it, the firmware running on a
device can make it a different device from a device tree perspective.
The device tree does its best to describe just the hardware but it can
get fuzzy. For instance the "VID/PID" of a USB device is usually
something programmable and could be updateable by a firmware change
but we still may need to encode the VID/PID of the firmware that is
intended to run on the device in the device tree.

Anyway, I'm happy to be quiet about this and fine if folks want to
continue to work towards a "unified" binding. It makes me a little
uncomfortable that I'll still end up listed as a "maintainer" of the
unified binding because I don't totally agree with it, but I'm also
pragmatic and I'd rather have something that can land.

-Doug

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ