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: <d9760c02-1b73-5703-7964-a2918e16af94@denx.de>
Date:   Tue, 28 Sep 2021 12:11:47 +0200
From:   Marek Vasut <marex@...x.de>
To:     Lucas Stach <l.stach@...gutronix.de>,
        Guido Günther <agx@...xcpu.org>
Cc:     Stefan Agner <stefan@...er.ch>, David Airlie <airlied@...ux.ie>,
        Daniel Vetter <daniel@...ll.ch>,
        Shawn Guo <shawnguo@...nel.org>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        Pengutronix Kernel Team <kernel@...gutronix.de>,
        Fabio Estevam <festevam@...il.com>,
        NXP Linux Team <linux-imx@....com>,
        Sam Ravnborg <sam@...nborg.org>,
        dri-devel@...ts.freedesktop.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>
Subject: Re: [PATCH] drm: mxsfb: Set proper default bus format when using a
 bridge

On 9/28/21 11:27 AM, Lucas Stach wrote:
> Am Dienstag, dem 28.09.2021 um 11:19 +0200 schrieb Guido Günther:
>> Hi,
>> On Tue, Sep 28, 2021 at 11:08:58AM +0200, Marek Vasut wrote:
>>> On 9/28/21 10:55 AM, Guido Günther wrote:
>>>> If a bridge doesn't do any bus format handling MEDIA_BUS_FMT_FIXED is
>>>> returned. Fallback to a reasonable default (MEDIA_BUS_FMT_RGB888_1X24) in
>>>> that case.
>>>>
>>>> This unbreaks e.g. using mxsfb with the nwl bridge and mipi panels.
>>>>
>>>> Fixes: b776b0f00f24 ("drm: mxsfb: Use bus_format from the nearest bridge if present")
>>>>
>>>> Signed-off-by: Guido Günther <agx@...xcpu.org>
>>>> ---
>>>>
>>>> I'll look at what needs to be done in nwl separately but this also
>>>> unbreaks other bridge seupts that don't to format negotiation yet.
>>>>
>>>>    drivers/gpu/drm/mxsfb/mxsfb_kms.c | 2 ++
>>>>    1 file changed, 2 insertions(+)
>>>>
>>>> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
>>>> index af6c620adf6e..4ef94cf686b0 100644
>>>> --- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
>>>> +++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
>>>> @@ -369,6 +369,8 @@ static void mxsfb_crtc_atomic_enable(struct drm_crtc *crtc,
>>>>    			drm_atomic_get_new_bridge_state(state,
>>>>    							mxsfb->bridge);
>>>>    		bus_format = bridge_state->input_bus_cfg.format;
>>>> +		if (bus_format == MEDIA_BUS_FMT_FIXED)
>>>> +			bus_format = MEDIA_BUS_FMT_RGB888_1X24;
>>>
>>> Shouldn't the NWL bridge return the correct format ?
>>
>> Yes it should and I'll send a separate patch for that but we currently
>> don't do anything meaningful at all if the bridge doesn't do format
>> negotiation and then fail setup in mxsfb_set_formats().
>>
>> I think we should at least preserve the status quo (as we do with the
>> non bridge case in b776b0f00f24 too).
>>
>> We could have a warning to spot drivers that don't do that yet and hence
>> the generic code returns MEDIA_BUS_FMT_FIXED.
>>
> That sounds sensible. Using a default format if we don't know what to
> do is going to be a unpleasant surprise for those with a display
> pipeline that doesn't work with the default format. So please add a
> dev_warn when we are doing this fallback.
> 
> Also I would argue that the NWL fix is the patch that should go in the
> stable tree. This one should only be a additional safety net, so I
> would drop the Fixes tag.

Indeed

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ