All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sui Jingfeng <sui.jingfeng@linux.dev>
To: Maxime Ripard <mripard@kernel.org>
Cc: Neil Armstrong <neil.armstrong@linaro.org>,
	Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/2] drm/bridge: Add 'struct device *' field to the drm_bridge structure
Date: Wed, 15 May 2024 22:53:00 +0800	[thread overview]
Message-ID: <d394ee32-4fa4-41a8-a5ca-c1c7f77f44d2@linux.dev> (raw)
In-Reply-To: <20240515-fair-satisfied-myna-480dea@penduick>

Hi,


On 5/15/24 22:30, Maxime Ripard wrote:
> On Wed, May 15, 2024 at 12:53:33AM +0800, Sui Jingfeng wrote:
>> Hi,
>>
>> On 2024/5/15 00:22, Maxime Ripard wrote:
>>> Hi,
>>>
>>> On Tue, May 14, 2024 at 11:40:43PM +0800, Sui Jingfeng wrote:
>>>> Because a lot of implementations has already added it into their drived
>>>> class, promote it into drm_bridge core may benifits a lot. drm bridge is
>>>> a driver, it should know the underlying hardware entity.
>>> Is there some actual benefits, or is it theoretical at this point?
>>
>>
>> I think, DRM bridge drivers could remove the 'struct device *dev'
>> member from their derived structure. Rely on the drm bridge core
>> when they need the 'struct device *' pointer.
> 
> Sure, but why do we need to do so?
> 
> The other thread you had with Jani points out that it turns out that
> things are more complicated than "every bridge driver has a struct
> device anyway", it creates inconsistency in the API (bridges would have
> a struct device, but not other entities), and it looks like there's no
> use for it anyway.
> 
> None of these things are deal-breaker by themselves, but if there's only
> downsides and no upside, it's not clear to me why we should do it at all.
> 


It can reduce boilerplate.


> Maxime

-- 
Best regards
Sui

  reply	other threads:[~2024-05-15 14:53 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-14 15:40 [PATCH 0/2] drm/bridge: Add 'struct device *' field to the drm_bridge structure Sui Jingfeng
2024-05-14 15:40 ` [PATCH 1/2] drm/bridge: Support finding bridge with struct device Sui Jingfeng
2024-05-15  9:39   ` Jani Nikula
2024-05-15 10:17     ` Sui Jingfeng
2024-05-15 10:28       ` Jani Nikula
2024-05-15 10:34         ` Sui Jingfeng
2024-05-15 11:33           ` Jani Nikula
2024-05-14 15:40 ` [PATCH 2/2] drm/bridge: Switch to use drm_bridge_add_with_dev() Sui Jingfeng
2024-05-14 16:22 ` [PATCH 0/2] drm/bridge: Add 'struct device *' field to the drm_bridge structure Maxime Ripard
2024-05-14 16:53   ` Sui Jingfeng
2024-05-15 14:30     ` Maxime Ripard
2024-05-15 14:53       ` Sui Jingfeng [this message]
2024-05-15 14:58         ` Maxime Ripard
2024-05-15 15:19           ` Sui Jingfeng
2024-05-16  8:25             ` Maxime Ripard
2024-05-16 10:40               ` Sui Jingfeng
2024-05-16 12:04                 ` Sui Jingfeng
2024-05-19 21:44                   ` Dmitry Baryshkov
2024-05-21  8:37                   ` Maxime Ripard
2024-05-21  8:34                 ` Maxime Ripard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d394ee32-4fa4-41a8-a5ca-c1c7f77f44d2@linux.dev \
    --to=sui.jingfeng@linux.dev \
    --cc=dmitry.baryshkov@linaro.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mripard@kernel.org \
    --cc=neil.armstrong@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.