Re: [PATCH v2 2/2] drm/bridge: waveshare-dsi: Add support for 1..4 DSI data lanes

["Luca Ceresoli" <luca.ceresoli@bootlin.com>]

Hi Marek,

On Tue Mar 3, 2026 at 1:59 PM CET, Marek Vasut wrote:
> On 3/3/26 8:56 AM, Maxime Ripard wrote:
>> On Mon, Mar 02, 2026 at 10:35:31PM +0100, Marek Vasut wrote:
>>> On 2/6/26 12:48 PM, Marek Vasut wrote:
>>>> On 1/15/26 3:39 AM, Marek Vasut wrote:
>>>>> Parse the data lane count out of DT. Limit the supported data lanes
>>>>> to 1..4 which is the maximum available DSI pairs on the connector of
>>>>> any known panels which may use this bridge. Internally, this bridge
>>>>> is an ChipOne ICN6211 which loads its register configuration from a
>>>>> dedicated storage and its I2C does not seem to be accessible. The
>>>>> ICN6211 also supports up to 4 DSI lanes, so this is a hard limit.
>>>>>
>>>>> To avoid any breakage on old DTs where the parsing of data lanes from
>>>>> DT may fail, fall back to the original hard-coded value of 2 lanes and
>>>>> warn user.
>>>>>
>>>>> The lane configuration is preconfigured in the bridge for each of the
>>>>> WaveShare panels. The 13.3" DSI panel works with 4-lane configuration,
>>>>> others seem to use 2-lane configuration. This is a hardware property,
>>>>> so the actual count should come from DT.
>>>>>
>>>>> Reviewed-by: Joseph Guo <qijian.guo@nxp.com>
>>>>> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
>>>>
>>>> Is it OK to apply these two patches now ?
>>>
>>> Can this be applied now ?
>>
>> It looks like you have a reviewed-by already, what's stoping you from
>> applying it yourself?
> I generally try to avoid applying my own patches, but if that is OK
> here, I will apply them ?

I fid it a bit weird as well, but it's the common practice in drm-misc, so
I do it when there are enough R-by / A-by.

One thing I'm never sure about is the definition of "enough R-by / A-by"
though. I used to kind of assume at least a maintainer listed in
MAINTAINERS should approve the patch. But that also seems not a rule for
drm-misc, at least for patches that impact only a specific driver and not
core or otherwise shared code, and/or which look "obviously correct".

Based on the above, I'm applying this series right now.

Luca

--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com