Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Low] Global variable lacks `static` qualifier after being localized to a single file --
commit 8f093246201046313865b72d1d462aeb11847f4f Author: Adrián Larumbe <[email protected]> drm/panfrost: Move lock and modparam initialisations into their subsystems The device init function feels a bit cluttered with things that should be done in the specific subsystems where those locks and lists are being used. Same goes for module parameters, it's best to limit them to the subsystems where they're relevant. > diff --git a/drivers/gpu/drm/panfrost/panfrost_gem.c > b/drivers/gpu/drm/panfrost/panfrost_gem.c > index 7b993a089af2d..15105b7f954bf 100644 > --- a/drivers/gpu/drm/panfrost/panfrost_gem.c > +++ b/drivers/gpu/drm/panfrost/panfrost_gem.c [ ... ] > @@ -11,10 +11,17 @@ > #include <drm/panfrost_drm.h> > #include <drm/drm_print.h> > #include "panfrost_device.h" > -#include "panfrost_drv.h" > #include "panfrost_gem.h" > #include "panfrost_mmu.h" > > +#ifdef CONFIG_TRANSPARENT_HUGEPAGE > +bool panfrost_transparent_hugepage = true; [Severity: Low] Since panfrost_transparent_hugepage was moved into panfrost_gem.c and its declaration was removed from panfrost_drv.h, should this be declared as static? Without the static qualifier, this variable is now exposed to the global namespace and triggers a Sparse warning ("symbol 'panfrost_transparent_hugepage' was not declared. Should it be static?"). > +module_param_named(transparent_hugepage, panfrost_transparent_hugepage, > bool, 0400); > +MODULE_PARM_DESC(transparent_hugepage, "Use a dedicated tmpfs mount point > with Transparent Hugepage enabled (true = default)"); > +#else > +#define panfrost_transparent_hugepage false > +#endif > + > int panfrost_gem_init(struct panfrost_device *pfdev) -- Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=3
