linux-kernel - Re: [PATCH] drm/bridge/synopsis: stop clobbering drvdata

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]

Date:   Tue, 09 Jan 2018 15:36:53 +0200
From:   Laurent Pinchart <laurent.pinchart@...asonboard.com>
To:     dri-devel@...ts.freedesktop.org
Cc:     Brian Norris <briannorris@...omium.org>,
        Doug Anderson <dianders@...omium.org>, hl@...k-chips.com,
        linux-rockchip@...ts.infradead.org,
        David Airlie <airlied@...ux.ie>,
        Jeffy Chen <jeffy.chen@...k-chips.com>,
        Philippe Cornu <philippe.cornu@...com>,
        linux-kernel@...r.kernel.org,
        Yannick Fertre <yannick.fertre@...com>,
        Nickey Yang <nickey.yang@...k-chips.com>, mka@...omium.org,
        Vincent Abriou <vincent.abriou@...com>
Subject: Re: [PATCH] drm/bridge/synopsis: stop clobbering drvdata

Hi Brian,

On Tuesday, 28 November 2017 20:21:23 EET Brian Norris wrote:
> On Tue, Nov 28, 2017 at 02:51:46PM +0200, Laurent Pinchart wrote:
> > Hi Brian,
> > 
> > Thank you for the patch.
> > 
> > I'd mention dw-mipi-dsi in the subject line as the directory contains the
> > dw-hdmi driver as well that this patch doesn't touch.
> 
> Yep. Does it need another tag in the subject? e.g., '.../dw-mipi-dsi:'?
> 
> > On Tuesday, 28 November 2017 03:05:38 EET Brian Norris wrote:
> >> Bridge drivers/helpers shouldn't be clobbering the drvdata, since a
> >> parent driver might need to own this.
> > 
> > By parent driver I assume you mean a glue driver that binds to the SoC-
> > specific compatible string for the DSI transmitter.
> 
> Indeed. Nickey picked this up for his Rockchip driver submission, but
> maybe we should reword the commit message a bit.

How about "drm: dw-mipi-dsi: Stop clobbering drvdata" ?

> >> Instead, let's return our
> >> 'dw_mipi_dsi' object and have callers pass that back to us for removal.
> >> 
> >> Signed-off-by: Brian Norris <briannorris@...omium.org>
> > 
> > Wouldn't it be cleaner to embed the dw_mipi_dsi structure in the parent-
> > specific data structure (struct dw_mipi_dsi_stm and struct
> > dw_mipi_dsi_rockchip when the "[PATCH v3 0/5] Update ROCKCHIP DSI driver
> > that uses dw-mipi-dsi bridge" patch series will land) instead of
> > allocating it dynamically ? We would then have a single object to track.
> 
> I suppose we could do that too. But that would require exposing the
> whole layout of 'struct dw_mipi_dsi' to users. Do we want to sacrifice
> the enforced separation for a little bit of nicer object handling?

I certainly don't think we should go for spaghetti code with all objects 
accessing each other :) On the other hand, we're talking about C code, and we 
thus have no way to enforce access restrictions in the compiler, so it's a 
lost battle anyway. I don't see an issue with exposing the object in the sense 
of moving its definition to a header file if it results in cleaner code. I 
think we need to trust developers not to abuse internal APIs, and if they do, 
catch it during review.

> Also, this was modeled a bit after the similar rework needed to untangle
> the drvdata handling in the Rockchip analogix DP driver vs. the analogix
> bridge DP code:
> 
> [PATCH v6 03/10] drm/bridge: analogix: Do not use device's drvdata
> https://patchwork.kernel.org/patch/10015875/

-- 
Regards,

Laurent Pinchart