linux-kernel - Re: [PATCH v9 27/28] media: iris: enable video driver probe of SM8250 SoC

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: <Z6I-4w8R5Hk1QYgG@hovoldconsulting.com>
Date: Tue, 4 Feb 2025 17:22:59 +0100
From: Johan Hovold <johan@...nel.org>
To: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
Cc: Dikshita Agarwal <quic_dikshita@...cinc.com>,
	Vikash Garodia <quic_vgarodia@...cinc.com>,
	Abhinav Kumar <quic_abhinavk@...cinc.com>,
	Mauro Carvalho Chehab <mchehab@...nel.org>,
	Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Philipp Zabel <p.zabel@...gutronix.de>,
	Hans Verkuil <hverkuil@...all.nl>,
	Sebastian Fricke <sebastian.fricke@...labora.com>,
	Bryan O'Donoghue <bryan.odonoghue@...aro.org>,
	Neil Armstrong <neil.armstrong@...aro.org>,
	Nicolas Dufresne <nicolas@...fresne.ca>,
	Uwe Kleine-König <u.kleine-koenig@...libre.com>,
	Jianhua Lu <lujianhua000@...il.com>,
	Stefan Schmidt <stefan.schmidt@...aro.org>,
	linux-media@...r.kernel.org, linux-arm-msm@...r.kernel.org,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
	Bjorn Andersson <andersson@...nel.org>
Subject: Re: [PATCH v9 27/28] media: iris: enable video driver probe of
 SM8250 SoC

On Tue, Feb 04, 2025 at 05:35:26PM +0200, Dmitry Baryshkov wrote:
> On Tue, Feb 04, 2025 at 10:52:45AM +0100, Johan Hovold wrote:

> > That's just not true. The rule is to not have two drivers for the same
> > hardware (even if we very rarely have accepted some well-motivated
> > exceptions).
> > 
> > I understand that you may have an unorthodox view of this as you work on
> > the MSM DRM driver, but hiding incomplete and broken code behind module
> > parameters so that you can game the upstreaming process (e.g. like you
> > did for the eDP PSR feature) is simply not a model that anyone should
> > follow.
> 
> Let me point you the aic7xxx story, we had, if my memory is correct,
> three drivers working with the same hardware at some point, during
> transition period.

As I also mentioned, there have been exceptions to the rule.

> Regarding eDP PSR. It wasn't my implementation, so that's not correct
> comparison.

Sure, but that module parameter is still there two years later, the
functionality is still incomplete and from what I've heard has since
also bitrotted (psr_enabled).

Done right and enabled by default this feature would have been very
useful giving, for example, users of the X13s a 2 h battery boost.
Instead, as expected, no one cares about fixing the code after it was
"mainlined" or runs the bits that did work often enough to detect when
it breaks further. Everyone loses.

> MDP5 -> DPU migration is mine and yes, it is implemented in
> this way as we can trigger CI jobs having a single kernel, as developers
> we can switch between MDP5 and DPU drivers in a quick way, etc.

I don't know the backstory there, but at least the commit message didn't
mention anything about a plan to transition from one to the other.

Johan