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?
