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] [day] [month] [year] [list]

Message-ID: <4a1c28b2ad4f701b9b2fe363ebf6acbab504e6ad@intel.com>
Date: Tue, 27 May 2025 22:40:49 +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, 27 May 2025, Maxime Ripard <mripard@...nel.org> wrote:
> On Tue, May 20, 2025 at 01:09:47PM +0300, Jani Nikula 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()?
>> 
>> 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.
>
> Yeah, I was thinking of something along the lines of:
>
> const struct drm_panel_funcs dummy_funcs = {};
>
> struct drm_panel *register_panel() {
>     struct faux_device *faux;
>     struct drm_panel *panel;
>     int ret;
>
>     faux = faux_device_create(...);
>     if IS_ERR(faux)
>        return ERR_CAST(faux);
>
>     return __devm_drm_panel_alloc(&faux->dev, sizeof(*panel), 0, &dummy_funcs, $CONNECTOR_TYPE);
> }
>
> And you have a panel, under your control, with exactly the same
> setup than anyone else.

This [1] is what I'm toying with now, but again, draft stuff. Using
__devm_drm_panel_alloc() directly like above does make it cleaner.

Long term it can be improved, but my first dab at refactoring to make
that happen is already like 15-20 patches, and it'll just have to wait
until after making stuff work at all first.

I'm not sure if the ACPI device I'm passing to devm_drm_panel_alloc() is
correct, but it'll have to be *some* ACPI device for the lookup to
work. I am blissfully ignorant about its lifetime, but as long as
drm_panel_add() and drm_panel_remove() remain as they are, I don't think
it leaks anything. Fingers crossed.


BR,
Jani.


[1] https://gitlab.freedesktop.org/jani/linux/-/commit/241f21487e5e9a8fa72e37a8eebcc36099e6a1ee

-- 
Jani Nikula, Intel