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]
Message-ID: <CACRpkdYif_h38TYDuSjY-0WkWNknFOe8n2Xe7zBydKxySrdZHA@mail.gmail.com>
Date:   Thu, 6 Jul 2023 23:36:29 +0200
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Doug Anderson <dianders@...gle.com>
Cc:     Cong Yang <yangcong5@...qin.corp-partner.google.com>,
        neil.armstrong@...aro.org, conor+dt@...nel.org,
        devicetree@...r.kernel.org, sam@...nborg.org,
        linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        robh+dt@...nel.org, krzysztof.kozlowski+dt@...aro.org,
        hsinyi@...gle.com
Subject: Re: [v4 4/4] drm/panel: Support for Starry-ili9882t TDDI MIPI-DSI panel

On Thu, Jul 6, 2023 at 11:25 PM Doug Anderson <dianders@...gle.com> wrote:

> In my mind it's really a tradeoff and I'm happy to go with whatever
> consensus that others agree with. What I'm never super happy with,
> though, is changing the bikeshed color too often, so I'd be really
> curious to hear Sam's thoughts on the issue and whether he'd like to
> see this driver broken out into a dozen drivers.

This is not question about a dozen drivers, to be clear.

I just want to break out the drivers that have an identifiable
display controller that differs from the others, especially this one.

The rest of the drivers inside of this boe driver I can't really tell,
they seem related? We don't know?

So the Ilitek ILI9882t is an obvious break-out.

For the rest, I guess I would be happier if the Chromium people
could use their leverage with vendors to muscle out the details
about display controller vendors and provide #defines for all
magic commands, we all dislike these opaque firmware-looking
jam tables.

Cong already stated that he indeed has the datasheet for the
ILI9882t controller at hand, had I come in earlier I would have
asked for all of those sequences to be provided with proper
#defines instead of 0xff 0x98 0x82 0x01... but I'm late to the
show.

Yours,
Linus Walleij

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ