Re: [PATCH v4 2/4] drm: mxsfb: Add optional DPI output bus-width configuration

[Luca Ceresoli]

On Wed Sep 16, 2026 at 4:30 PM CEST, Luca Ceresoli wrote:
> On Wed Sep 16, 2026 at 1:43 PM CEST, Francesco Dolcini wrote:
>> On Wed, Sep 16, 2026 at 01:19:08PM +0200, Luca Ceresoli wrote:
>>> On Wed Sep 16, 2026 at 11:15 AM CEST, Francesco Dolcini wrote:
>>> > Hello Luca,
>>> >
>>> > On Wed, Sep 16, 2026 at 10:42:13AM +0200, Luca Ceresoli wrote:
>>> >> > LCDIF programs LCD_DATABUS_WIDTH from the selected media bus format. The
>>> >> > format reported by the downstream panel or bridge describes the display
>>> >> > input, but it does not describe how the LCDIF data pins are physically
>>> >> > wired on the board.
>>> >> >
>>> >> > These can differ. For example, a 16-bit LCDIF bus can be connected to a
>>> >> > 24-bit display by wiring the available color bits to the corresponding
>>> >> > display inputs. In that case, using the display's 24-bit format to
>>> >> > configure LCDIF selects the wrong data-bus mode and changes the assignment
>>> >> > of color bits on the LCD_DATA pins.
>>> >> >
>>> >> > Read the optional bus-width endpoint property from the LCDIF output port
>>> >> > and use it to select the media bus format used to configure LCDIF. This
>>> >> > allows the LCDIF bus mode to describe the physical interface
>>> >> > independently of the downstream display format.
>>> >> >
>>> >> > When the optional property is absent, or it has an invalid value, continue
>>> >> > using the format reported by the downstream display device, preserving
>>> >> > the existing behavior. The code is not validating the DT for
>>> >> > correctness and just fall back to the previous behavior in case of
>>> >> > errors.
>>> >>
>>> >> Why? Generally speaking errors are better spotted immediately, not ignored
>>> >> silently.
>>> >
>>> > My understanding is that the C driver code should not validate the DT
>>> > and that this is the general recommendation when parsing properties from
>>> > the DT.
>>> >
>>> > The DT checker is going to spot errors in the DT even earlier and in a
>>> > static way.

Ah, I forgot... I fully agree static build-time checks are way better than
runtime error checking code. But they are not done as a mandatory and
unconditional step during a build, and so not everybody runs them. Moreover
checks are added over time, so even if all checks pass today some might
fail in the future.

As a result there are plenty of devices out there with invalid dtbs, and
they just work by chance.

It's the hard reality I'm afraid. :(

Luca

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