[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <02380e49-7848-c968-ef6a-bc64d87d6228@collabora.com>
Date: Tue, 5 Sep 2023 10:03:10 +0200
From: AngeloGioacchino Del Regno
<angelogioacchino.delregno@...labora.com>
To: Michael Walle <mwalle@...nel.org>
Cc: NĂcolas F . R . A . Prado
<nfraprado@...labora.com>, Chun-Kuang Hu <chunkuang.hu@...nel.org>,
Philipp Zabel <p.zabel@...gutronix.de>,
David Airlie <airlied@...il.com>,
Daniel Vetter <daniel@...ll.ch>,
Matthias Brugger <matthias.bgg@...il.com>,
"Nancy . Lin" <nancy.lin@...iatek.com>,
Frank Wunderlich <frank-w@...lic-files.de>,
Jitao Shi <jitao.shi@...iatek.com>,
Stu Hsieh <stu.hsieh@...iatek.com>,
dri-devel@...ts.freedesktop.org,
linux-mediatek@...ts.infradead.org, linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v3 2/2] drm/mediatek: dpi/dsi: fix possible_crtcs
calculation
Il 05/09/23 09:58, Michael Walle ha scritto:
>> At this point, I think that it would be sane to change this function to
>> return a signed type, so that we can return -ENOENT if we couldn't find
>> any DDP path (so, if we couldn't find any possible crtc).
>
> Fair enough, but should it be part of the fixes commit or a different one?
>
> -michael
I would say that this should be part of the Fixes commit: after all, you're
fixing a case in which the possible_crtcs calculation *may fail*, so the
error handling for this possible failure is, indeed, one part of the fix :-)
Angelo
Powered by blists - more mailing lists