linux-kernel - Re: [PATCH 00/20] drm/panel: Move to using mipi_dsi_*

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: <ynmxaimdwkwfiryz5le5vpnfh5fzh5se4ebyqzkbnq355me76x@yxtyan3niivb>
Date: Tue, 18 Feb 2025 14:14:43 +0200
From: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
To: Maxime Ripard <mripard@...nel.org>
Cc: Doug Anderson <dianders@...omium.org>, 
	Anusha Srivatsa <asrivats@...hat.com>, Neil Armstrong <neil.armstrong@...aro.org>, 
	Jessica Zhang <quic_jesszhan@...cinc.com>, Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, 
	Thomas Zimmermann <tzimmermann@...e.de>, David Airlie <airlied@...il.com>, 
	Simona Vetter <simona@...ll.ch>, Joel Selvaraj <jo@...amily.in>, Ondrej Jirman <megi@....cz>, 
	Javier Martinez Canillas <javierm@...hat.com>, Jianhua Lu <lujianhua000@...il.com>, 
	Robert Chiras <robert.chiras@....com>, Artur Weber <aweber.kernel@...il.com>, 
	Jonathan Corbet <corbet@....net>, dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org, 
	linux-doc@...r.kernel.org, Tejas Vipin <tejasvipin76@...il.com>
Subject: Re: [PATCH 00/20] drm/panel: Move to using mipi_dsi_*_multi()
 variants when available

On Tue, Feb 18, 2025 at 10:55:49AM +0100, Maxime Ripard wrote:
> On Fri, Feb 14, 2025 at 08:26:02AM -0800, Doug Anderson wrote:
> > Hi,
> > 
> > On Thu, Feb 13, 2025 at 12:44 PM Anusha Srivatsa <asrivats@...hat.com> wrote:
> > >
> > > A lot of mipi API are deprecated and have a _multi() variant
> > > which is the preferred way forward. This covers  TODO in the
> > > gpu Documentation:[1]
> > >
> > > An incomplete effort was made in the previous version
> > > to address this[2]. It removed on the mipi_dsi_dcs_write_seq()
> > > and mipi_dsi_generic_write_seq_multi() with the respective
> > > replacemts and not the rest of the API.
> > 
> > You didn't seem to take most of the suggestions I gave in response to
> > your v1 [3]. Specifically:
> > 
> > a) I asked that you CC Tejas. I've added him again.
> > 
> > b) I asked that you CC me on the whole patch series, which you didn't
> > do. I can find them, but I'd find it convenient in this case for them
> > to be in my Inbox.
> > 
> > The first patch conflicts with what Tejas already landed in
> > drm-misc-next. See commit 8025f23728e9 ("drm/panel:
> > xinpeng-xpp055c272: transition to mipi_dsi wrapped functions"). The
> > second patch _also_ conflicts with what Tejas already landed. See
> > commit f4dd4cb79f9e ("drm/panel: visionox-r66451: transition to
> > mipi_dsi wrapped functions"). Later patches also also conflict. See
> > commit 0d6c9edf9e5b ("drm/panel: ebbg-ft8719: transition to mipi_dsi
> > wrapped functions"), commit ce8c69ec90ca ("drm/panel:
> > samsung-s6e88a0-ams452ef01: transition to mipi_dsi wrapped
> > functions"), and commit 7e3bf00047cd ("drm/panel: sharp-ls060t1sx01:
> > transition to mipi_dsi wrapped functions"). Maybe you should sync up
> > with drm-misc-next before submitting.
> 
> Yes, you should definitely work from drm-misc-next there, and sync with
> Tejas.
> 
> > I also questioned whether this really made sense to try to do with a
> > Coccinelle script and I still don't think so. It looks like Dmitry has
> > already reviewed the first few of your patches and has repeated my
> > advice. If you want to help with the effort of addressing this TODO
> > item then that's great, but I'll stop reviewing (and start silently
> > deleting) any future submissions of yours that say that they're done
> > entirely with a Coccinelle script unless you address this point and
> > convince me that your Coccinelle script is really smart enough to
> > handle all the corner cases. I'll also assert that you should review
> > Tejas's submissions to see how these conversions are expected to go.
> 
> I couldn't find that in your first answer though. What corner cases do
> you have in mind, and why do you think coccinelle can't handle them?

As can be seen from the reviews:

- sleeps between DSI calls
- properly propagating the error at the end of the function
- making decision whether to create the context at the caller or the
  callee side. E.g. in patch 8 it is better to allocate context in
  hx8394_enable() and pass it to .init_sequence() instead of keeping
  some of error handling.

> Also, why do you think ignoring a contributor after a second mistake is
> a reasonable reaction?
> 
> Anusha, most of those comments aren't the end of the discussion though.
> If you feel like something's not clear enough or ambiguous, feel free to
> ask for more details and keep the discussion going.

>From my side: feel free to ask for the details if any of the emails is
not clear enough. At the same time, please review your patches before
sending them. Returning 0 in case there was an error is an obvious
issue.

-- 
With best wishes
Dmitry