On Mon, Feb 23, 2026 at 10:41:04PM +0100, Danilo Krummrich wrote: > On Mon Feb 23, 2026 at 9:46 PM CET, Deborah Brouwer wrote: > > Currently the `TyrDriver` struct implements both `platform::Driver` and > > `drm::Driver`. For clarity, split up these two roles: > > - Introduce `TyrPlatformDeviceData` to implement `platform::Driver`, and > > I think this should be TyrPlatformDriverData instead, i.e. it is the driver's > private data that happens to be stored in (and owned by) the platform device. > > The corresponding C setter is also called platform_set_drvdata() and not > platform_set_devdata().
Yeah, I think you’re right, since we use this struct for platform::Driver. I’ll rename it and send a v3. > > > - Introduce `TyrDrmDriver` to implement `drm::Driver`. > > > > Also rename other variables to reflect their roles in the DRM context: > > - Rename `TyrDevice` to `TyrDrmDevice` > > - Rename `TyrData` to `TyrDrmDeviceData` > > Although it might sound contradictory at first, I think for a drm::Device it > is > OK to name it TyrDrmDeviceData as opposed to TyrDrmDriverData (although that > would make sense as well and I'd probably prefer that). > > The reason is that a platform::Device being a bus device may store different > *driver specific* data types thoughout its whole lifetime, i.e. a platform > device may be bound to multiple different drivers throughout its lifetime. > > But a drm::Device being a class device is always *statically* typed over it's > private data type, i.e. drm::Device<TyrDrmDeviceData>. I'd definitely like to keep TyrDrmDeviceData for this struct because of its relationship to the drm::Device. Thanks for your review. > > > - Rename `File` to `TyrDrmFileData` > > - Rename `DrmFile` to `TyrDrmFile` > > > > No functional changes are intended. > > > > Co-developed-by: Boris Brezillon <[email protected]> > > Signed-off-by: Boris Brezillon <[email protected]> > > Signed-off-by: Deborah Brouwer <[email protected]> > > Otherwise LGTM.
