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@xxxxxxxxxxxx> > > > > 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
