[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6khhnjtdcjvebnffrqlavowld4gvgcpnxplcinkja5xv3yefct@vjnmj72dfqtg>
Date: Mon, 20 May 2024 00:44:40 +0300
From: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
To: Sui Jingfeng <sui.jingfeng@...ux.dev>
Cc: Maxime Ripard <mripard@...nel.org>,
Neil Armstrong <neil.armstrong@...aro.org>, dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/2] drm/bridge: Add 'struct device *' field to the
drm_bridge structure
On Thu, May 16, 2024 at 08:04:59PM +0800, Sui Jingfeng wrote:
>
>
> On 5/16/24 18:40, Sui Jingfeng wrote:
> > use 'to_i2c_client(bridge->dev)' to retrieve the pointer
>
> to_i2c_client(bridge->kdev).
>
> Besides, this also means that we don't need to add the fwnode
> pointer into struct drm_bridge as member. Relief the conflicts
> with other reviewers if the work of switching to fwnode is still
> needed. As for majorities cases (1 to 1), of_node and fwnode can
> be retrieved with 'struct device *' easily. The aux-bridge.c and
> aux-hdp-bridge.c can also be converted too easily.
>
> of_node, fwnode, swnode and device properties are all belong to
> the backing device structure itself. It can be more natural to use
> device_proterty_read_xxx() APIs after init time, Which in turn
> avoid the need to acquire and duplicate all properties another
> time in the driver private structure.
This doesn't sound 100% correct. This is going to drop the possibile
case when bridge driver uses child DT or FW node under the main device
node. For example of such usecase see drivers/usb/typec/tcpm/qcom/qcom_pmic_typec.c
>
> We could do the programming around the 'struct device *.', remove
> a batch of boilerplate.
--
With best wishes
Dmitry
Powered by blists - more mailing lists