linux-kernel - Re: [PATCH v4 2/4] drm/panel: Add refcount support

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: <8210f7fc0dbcfc5b1eea47ccb762c7e53b45236a@intel.com>
Date: Fri, 23 May 2025 14:34:05 +0300
From: Jani Nikula <jani.nikula@...ux.intel.com>
To: Maxime Ripard <mripard@...nel.org>
Cc: Anusha Srivatsa <asrivats@...hat.com>, Neil Armstrong
 <neil.armstrong@...aro.org>, Jessica Zhang <quic_jesszhan@...cinc.com>,
 Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, Thomas Zimmermann
 <tzimmermann@...e.de>, David Airlie <airlied@...il.com>, Simona Vetter
 <simona@...ll.ch>, dri-devel@...ts.freedesktop.org,
 linux-kernel@...r.kernel.org, Luca Ceresoli <luca.ceresoli@...tlin.com>
Subject: Re: [PATCH v4 2/4] drm/panel: Add refcount support

On Tue, 20 May 2025, Jani Nikula <jani.nikula@...ux.intel.com> wrote:
> Maxime -
>
> I'm cutting a lot of context here. Not because I don't think it deserves
> an answer, but because I seem to be failing at communication.
>
> On Mon, 19 May 2025, Maxime Ripard <mripard@...nel.org> wrote:
>> You still haven't explained why it would take anything more than
>> registering a dumb device at probe time though.
>
> With that, do you mean a dumb struct device, or any struct device with a
> suitable lifetime, that we'd pass to devm_drm_panel_alloc()?

I'm no expert in ACPI, but I think it needs to be a struct device
embedded inside struct acpi_device to implement the
drm_panel_add_follower() lookup for ACPI.

It would be natural to embed struct drm_panel inside struct intel_panel,
except we need struct intel_panel way before we have figured out the
acpi device. We need struct intel_panel at connector register time, acpi
devices currently get figured out after all connectors have been
registered. I'm trying to see if we can change that, but it doesn't look
easy. Separate allocation and initialization would cover that.

> Is using devm_drm_panel_alloc() like that instead of our own allocation
> with drm_panel_init() the main point of contention for you? If yes, we
> can do that.

As devm_drm_panel_alloc() forces embedding, and we can't easily embed
drm_panel inside intel_panel, even that would need a dummy wrapper
struct.

BR,
Jani.

-- 
Jani Nikula, Intel