<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Wed, Feb 19, 2025 at 8:35 AM Maxime Ripard <<a href="mailto:mripard@kernel.org">mripard@kernel.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, Feb 19, 2025 at 11:11:33AM +0200, Dmitry Baryshkov wrote:<br>
> On Tue, Feb 18, 2025 at 04:52:53PM +0100, Maxime Ripard wrote:<br>
> > On Tue, Feb 18, 2025 at 02:14:43PM +0200, Dmitry Baryshkov wrote:<br>
> > > On Tue, Feb 18, 2025 at 10:55:49AM +0100, Maxime Ripard wrote:<br>
> > > > On Fri, Feb 14, 2025 at 08:26:02AM -0800, Doug Anderson wrote:<br>
> > > > > Hi,<br>
> > > > > <br>
> > > > > On Thu, Feb 13, 2025 at 12:44 PM Anusha Srivatsa <<a href="mailto:asrivats@redhat.com" target="_blank">asrivats@redhat.com</a>> wrote:<br>
> > > > > ><br>
> > > > > > A lot of mipi API are deprecated and have a _multi() variant<br>
> > > > > > which is the preferred way forward. This covers  TODO in the<br>
> > > > > > gpu Documentation:[1]<br>
> > > > > ><br>
> > > > > > An incomplete effort was made in the previous version<br>
> > > > > > to address this[2]. It removed on the mipi_dsi_dcs_write_seq()<br>
> > > > > > and mipi_dsi_generic_write_seq_multi() with the respective<br>
> > > > > > replacemts and not the rest of the API.<br>
> > > > > <br>
> > > > > You didn't seem to take most of the suggestions I gave in response to<br>
> > > > > your v1 [3]. Specifically:<br>
> > > > > <br>
> > > > > a) I asked that you CC Tejas. I've added him again.<br>
> > > > > <br>
> > > > > b) I asked that you CC me on the whole patch series, which you didn't<br>
> > > > > do. I can find them, but I'd find it convenient in this case for them<br>
> > > > > to be in my Inbox.<br>
> > > > > <br>
> > > > > The first patch conflicts with what Tejas already landed in<br>
> > > > > drm-misc-next. See commit 8025f23728e9 ("drm/panel:<br>
> > > > > xinpeng-xpp055c272: transition to mipi_dsi wrapped functions"). The<br>
> > > > > second patch _also_ conflicts with what Tejas already landed. See<br>
> > > > > commit f4dd4cb79f9e ("drm/panel: visionox-r66451: transition to<br>
> > > > > mipi_dsi wrapped functions"). Later patches also also conflict. See<br>
> > > > > commit 0d6c9edf9e5b ("drm/panel: ebbg-ft8719: transition to mipi_dsi<br>
> > > > > wrapped functions"), commit ce8c69ec90ca ("drm/panel:<br>
> > > > > samsung-s6e88a0-ams452ef01: transition to mipi_dsi wrapped<br>
> > > > > functions"), and commit 7e3bf00047cd ("drm/panel: sharp-ls060t1sx01:<br>
> > > > > transition to mipi_dsi wrapped functions"). Maybe you should sync up<br>
> > > > > with drm-misc-next before submitting.<br>
> > > > <br>
> > > > Yes, you should definitely work from drm-misc-next there, and sync with<br>
> > > > Tejas.<br>
> > > > <br>
> > > > > I also questioned whether this really made sense to try to do with a<br>
> > > > > Coccinelle script and I still don't think so. It looks like Dmitry has<br>
> > > > > already reviewed the first few of your patches and has repeated my<br>
> > > > > advice. If you want to help with the effort of addressing this TODO<br>
> > > > > item then that's great, but I'll stop reviewing (and start silently<br>
> > > > > deleting) any future submissions of yours that say that they're done<br>
> > > > > entirely with a Coccinelle script unless you address this point and<br>
> > > > > convince me that your Coccinelle script is really smart enough to<br>
> > > > > handle all the corner cases. I'll also assert that you should review<br>
> > > > > Tejas's submissions to see how these conversions are expected to go.<br>
> > > > <br>
> > > > I couldn't find that in your first answer though. What corner cases do<br>
> > > > you have in mind, and why do you think coccinelle can't handle them?<br>
> > > <br>
> > > As can be seen from the reviews:<br>
> > > <br>
> > > - sleeps between DSI calls<br>
> > > - properly propagating the error at the end of the function<br>
> > <br>
> > These two are legitimate feedback, but I don't see how coccinelle cannot<br>
> > deal with them.<br>
> <br>
> Maybe it can. both issues were pointed out during review of the first<br>
> series, there was no improvement here. I'd really ask to perform<br>
> conversion of a single driver, so that the script (or post-script<br>
> fixups) can be improved. I'd still expect that Anusha actually reviews<br>
> the changed driver before posting it and verifies that there is no<br>
> regression in the logic / error reporting.<br>
<br>
Yeah, it makes sense, thanks!<br></blockquote><div><br></div><div>Dmitry, Doug,</div><div><br></div><div>Sorry for the late response, I was out. A lot of the confusion and effort  could have been saved had I worked on the -misc branch. My bad.  WIll keep the rest of the feedback in mind and address one driver at a time to avoid an overhaul of changes. Thanks for taking time out to guide me in the right direction!  <br></div><div><br></div><div>Anusha<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Maxime<br>
</blockquote></div></div>