On Thu, Sep 19, 2024 at 03:03:19PM +0200, Christian Brauner wrote:
> On Wed, Sep 18, 2024 at 02:40:46PM GMT, Liviu Dudau wrote:
> > Hi Christian,
> >
> > > This is another flag that is statically set and doesn't need to use up
> > > an FMODE_* bit. Move it to ->fop_flags and free up another FMODE_* bit.
> > >
> > > (1) mem_open() used from proc_mem_operations
> > > (2) adi_open() used from adi_fops
> > > (3) drm_open_helper():
> > > (3.1) accel_open() used from DRM_ACCEL_FOPS
> > > (3.2) drm_open() used from
> > > (3.2.1) amdgpu_driver_kms_fops
> > > (3.2.2) psb_gem_fops
> > > (3.2.3) i915_driver_fops
> > > (3.2.4) nouveau_driver_fops
> > > (3.2.5) panthor_drm_driver_fops
> > > (3.2.6) radeon_driver_kms_fops
> > > (3.2.7) tegra_drm_fops
> > > (3.2.8) vmwgfx_driver_fops
> > > (3.2.9) xe_driver_fops
> > > (3.2.10) DRM_GEM_FOPS
> > > (3.2.11) DEFINE_DRM_GEM_DMA_FOPS
> > > (4) struct memdev sets fmode flags based on type of device opened. For
> > > devices using struct mem_fops unsigned offset is used.
> > >
> > > Mark all these file operations as FOP_UNSIGNED_OFFSET and add asserts
> > > into the open helper to ensure that the flag is always set.
> > >
> > > Signed-off-by: Christian Brauner <brauner@xxxxxxxxxx>
> >
> > Your patch seems to be missing the panthor_drm_driver_fops changes. I've
> > discovered that on linux-next your patch triggers a WARN() during my testing.
>
> Yeah, I've added a WARN_ON_ONCE() to catch such cases. Good that it worked.
>
> >
> > I've added the following change to my local tree to fix the warning.
>
> I would send a fixes PR soon. Do you want me to send a fix for this
> along with this or are you taking this upstream soon yourself?
Was your series pulled into v6.12?
I will send a patch and once reviewed I will push it into the relevant drm-misc branch.
Best regards,
Liviu
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
¯\_(ツ)_/¯
