Re: [PATCH 0/5] rust: drm: add panel bindings

[Maxime Ripard]

Hi,

On Mon, Aug 17, 2026 at 01:40:45PM +0200, Albert Esteve wrote:
> This series adds Rust abstractions for the DRM panel subsystem,
> covering both the consumer and producer sides of the API.
> This helps closing the gap so that future panel drivers
> can be written directly in Rust.
> 
> Background
> ----------
> The DRM panel C API has been progressively hardened over the past
> year (see [1], [2], and [3]). All panel drivers were fully migrated
> to kref-based allocation via devm_drm_panel_alloc(). Panel lookup
> functions (i.e., of_drm_find_panel() and find_panel_by_fwnode())
> were also updated to acquire a reference before returning.
> 
> Note this series depends on [3] being merged in the base
> tree. Currently it has been only applied to drm-misc-next.
> The other series mentioned above are already part of the
> base for the current version of this series.
> 
> As a personal note, part of my motivation for creating this series
> was learning more about Rust in the kernel. I would appreciate
> feedback on Rust-specific idioms or kernel conventions used here
> that I may have missed.
> 
> What this series does
> ---------------------
> Patch 1 adds of::Node, a Rust wrapper for struct device_node
> implementing AlwaysRefCounted. C helpers are added so that of_node_get()
> and of_node_put() are reachable from Rust independently of CONFIG_OF_DYNAMIC.
> 
> Patch 2 adds drm::Connector, a minimal Rust wrapper for
> struct drm_connector. Its sole purpose is to provide a typed reference
> for the get_modes() callback argument; no ownership or refcounting is
> exposed at this stage.
> 
> Patch 3 adds the consumer side of the panel abstraction:
> - Panel wraps struct drm_panel and implements AlwaysRefCounted via
>   drm_panel_get/put. Consumer lifecycle methods are exposed as safe wrappers.
> - PanelOrientation wraps enum drm_panel_orientation and provides
>   from_of_node() to read the "rotation" device tree property.
> - Registration manages the panel's presence in the global registry
>   via drm_panel_add/remove, decoupling registry lifetime from
>   reference count lifetime.
> 
> Patch 4 adds the producer side:
> - PanelFuncs is a #[vtable] trait that panel drivers implement to
>   provide their callbacks. All but get_modes are optional.
> - Panel::new wraps __devm_drm_panel_alloc, returning an ARef<Panel>.
>   Registration with the global registry is kept separate via
>   Registration::register, following the pattern of drm::Device::new.
> - ConnectorType mirrors the DRM_MODE_CONNECTOR_* defines from
>   include/uapi/drm/drm_mode.h, required by Panel::new to specify the
>   panel's connector type.
> 
> Patch 5 adds gated tests, covering data type conversions and layout
> invariants.

So while it's definitely welcome on principle, I wonder if panels would
be a place to invest in at the moment

The series
https://lore.kernel.org/dri-devel/20260814-drm-bridge-every-panel-v1-0-19cd5277cc8d@xxxxxxxxxxx/
is likely to move every consumer to use bridges exclusively.

https://lore.kernel.org/ksummit/0fa2fb42-0714-49f7-ba43-22928e1dd488@xxxxxxxxxx/
raised a discussion that the panel API is very limited at the moment
(while the bridge API isn't, or could be much more easily extended).

This is supposed to be discussed at plumbers, but I seriously think the
outcome of that discussion would be to just deprecate panels.

Bridges would be a much more long-term-proof investment.

Maxime

Attachment: signature.asc
Description: PGP signature