linux-kernel - Re: [PATCH 1/4] ARM: dts: omap3-n900: fix LCD reset line polarity

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: <Y0fxxsk+e2o0wYZV@atomide.com>
Date:   Thu, 13 Oct 2022 14:08:54 +0300
From:   Tony Lindgren <tony@...mide.com>
To:     Tomi Valkeinen <tomi.valkeinen@...asonboard.com>
Cc:     Dmitry Torokhov <dmitry.torokhov@...il.com>,
        Sebastian Reichel <sre@...nel.org>,
        Benoît Cousson <bcousson@...libre.com>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Rob Herring <robh+dt@...nel.org>, devicetree@...r.kernel.org,
        linux-omap@...r.kernel.org, linux-kernel@...r.kernel.org,
        Ivaylo Dimitrov <ivo.g.dimitrov.75@...il.com>
Subject: Re: [PATCH 1/4] ARM: dts: omap3-n900: fix LCD reset line polarity

Hi,

* Tomi Valkeinen <tomi.valkeinen@...asonboard.com> [221013 06:13]:
> I would just go with the above for the time being. It should be an easy
> change, and as these omapfb and drm panel drivers are kind of copies of each
> other, I think it makes sense to use the same code in both.

Maybe if a fix is needed, sure let's fix things first, then drop
the unused panel drivers.

We already have drivers/gpu/drm/panel driver for both of these two
omapfb panels:

drivers/video/fbdev/omap2/omapfb/displays/panel-sony-acx565akm.c
drivers/video/fbdev/omap2/omapfb/displays/panel-dsi-cm.c

The compatible strings used translate to these dts files:

arch/arm/boot/dts/motorola-mapphone-common.dtsi
arch/arm/boot/dts/omap3-n900.dts
arch/arm/boot/dts/omap3-n950.dts
arch/arm/boot/dts/omap4-sdp.dts

These devices work with omapdrm and there should not be any need to
stick with the omapfb driver. We can just drop the omapfb panel
drivers for panel-sony-acx565akm.c and panel-dsi-cm.c. Let's put
the limited effort where there is activity instead :)

The vrfb rotation work has been discussed on the lists, so seems
like we will eventually have that for omapdrm. Meanwhile, software
rotation is being used for postmarketos and leste with omapdrm
AFAIK.

> That said, I personally don't mind fixing the dts files and the drivers, and
> even dropping the omapfb panel drivers. However, as I don't know if someone
> needs the omapfb drivers or has to use an old dtb, I don't want to step on
> that possible mine field. If someone else wants to go there (without my
> involvement), fine for me =).

I belive the only valid use case for omap2 omapfb is the n8x0 rfbi
driver that has no omapdrm driver.

Regards,

Tony