linux-kernel - Re: [PATCH v1 2/2] drm/bridge/synopsys: dsi: Add a warning msg on dsi read operations

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: <20180124181449.2fi5l3wdllvxn5re@ban.mtv.corp.google.com>
Date:   Wed, 24 Jan 2018 10:14:49 -0800
From:   Brian Norris <briannorris@...omium.org>
To:     Philippe CORNU <philippe.cornu@...com>
Cc:     Archit Taneja <architt@...eaurora.org>,
        Andrzej Hajda <a.hajda@...sung.com>,
        Laurent Pinchart <Laurent.pinchart@...asonboard.com>,
        David Airlie <airlied@...ux.ie>,
        Benjamin Gaignard <benjamin.gaignard@...aro.org>,
        Bhumika Goyal <bhumirks@...il.com>,
        "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
        Linux Kernel <linux-kernel@...r.kernel.org>,
        Sandy Huang <hjc@...k-chips.com>,
        Heiko Stubner <heiko@...ech.de>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "open list:ARM/Rockchip SoC..." <linux-rockchip@...ts.infradead.org>,
        Yannick FERTRE <yannick.fertre@...com>,
        Vincent ABRIOU <vincent.abriou@...com>,
        Alexandre TORGUE <alexandre.torgue@...com>,
        Maxime Coquelin <mcoquelin.stm32@...il.com>,
        Ludovic BARRE <ludovic.barre@...com>,
        Mickael REULIER <mickael.reulier@...com>
Subject: Re: [PATCH v1 2/2] drm/bridge/synopsys: dsi: Add a warning msg on
 dsi read operations

Hi Philippe,

On Wed, Jan 24, 2018 at 01:22:04PM +0000, Philippe CORNU wrote:
> On 01/23/2018 10:28 PM, Brian Norris wrote:
> > I see you sent this out already today, while I only just responded
> > (late) to your questions about it... oh well :)
> > 
> 
> I got a short period to clean-up and adds features to this driver (1.31 
> ip version + maybe the read feature), sorry to have not wait a single 
> day more.

No problem. The key word was "late"; my mail was buried enough I just
missed responding. Not your fault!

> > On Tue, Jan 23, 2018 at 6:26 AM, Philippe Cornu <philippe.cornu@...com> wrote:
> >> The DCS/GENERIC DSI read feature is not yet implemented so it
> >> is important to warn the host_transfer() caller in case of
> >> read operation requests.
> >>
> >> Signed-off-by: Philippe Cornu <philippe.cornu@...com>
> >> ---
> >>   drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 9 ++++++++-
> >>   1 file changed, 8 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> >> index 096cf5e5bb30..e46ddff8601c 100644
> >> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> >> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> >> @@ -417,7 +417,14 @@ static ssize_t dw_mipi_dsi_host_transfer(struct mipi_dsi_host *host,
> >>          if (ret)
> >>                  return ret;
> >>
> >> -       nb_bytes = packet.size;
> >> +       if (msg->rx_buf && msg->rx_len > 0) {
> > 
> > It feels like you should do this check *before* you start writing
> > anything. It's possible to have a combination TX/RX command, and it
> > would be counterintuitive to only do half the operation then return
> > with an argument error.
> > 
> 
> Many thanks for your review.
> 
> I agree with your comments.
> 
> Well, my patch is not good at all because it contains a small part of 
> the read feature I am writing... but it is not the purpose of this patch.
> 
> No excuse, sorry guys for making you waste time.

No worries. These weren't that bad anyway, just a little suboptimal :)

> I will re-write a new patch 100% decorrelated from a possible future 
> read feature.

Yeah, that would probably work best. It's hard to write and review good
"intermediate" code; we should write it as if the code will last as-is.

> I could also wait until I have a working read feature but as it could 
> take some times, I prefer warning users asap.

Sounds good.

[snip]

Thanks,
Brian