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] [day] [month] [year] [list]

Message-ID: <20221013131756.wzn6pea4thwmwipb@mercury.elektranox.org>
Date:   Thu, 13 Oct 2022 15:17:56 +0200
From:   Sebastian Reichel <sre@...nel.org>
To:     Tony Lindgren <tony@...mide.com>
Cc:     Tomi Valkeinen <tomi.valkeinen@...asonboard.com>,
        Dmitry Torokhov <dmitry.torokhov@...il.com>,
        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,

On Thu, Oct 13, 2022 at 02:08:54PM +0300, Tony Lindgren wrote:
> 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 :)

FWIW

Acked-by: Sebastian Reichel <sre@...nel.org>

for removal of those two omapfb panel drivers.

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

Is that upstream? omapfb (and omapdrm) both have this:

	/*
	 * HACK
	 * We don't have a working driver for rfbi, so skip it here always.
	 * Otherwise dss will never get probed successfully, as it will wait
	 * for rfbi to get probed.
	 */
	if (strstr(dev_name(dev), "rfbi"))
		return 0;

I've seen a few old drivers being removed by marking them as BROKEN
(and updating Kconfig help text to explain the situation). Then the
code is dropped 1-2 cycles later assuming nobody complained.

-- Sebastian

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)