On Tue, Jan 4, 2022 at 3:16 PM Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx> wrote: > > On Mon, 3 Jan 2022 12:58:46 -0500 > Arnd Bergmann <arnd@xxxxxxxx> wrote: > > > On Mon, Jan 3, 2022 at 10:24 AM Jonathan Cameron <jic23@xxxxxxxxxx> wrote: > > > On Sun, 2 Jan 2022 09:15:06 -0500 Arnd Bergmann <arnd@xxxxxxxx> wrote: > > > > > > That came up in discussion of the patch series introducing this macro > > > https://lore.kernel.org/linux-pm/20211216110936.6ccd07d3@jic23-huawei/ > > > > > > Most of the cases that don't define it as static > > > also export the symbol for use by other modules so the approach of letting > > > the compiler detect it as dead code won't always work. > > > > > > Exceptions from a bit of grepping are > > > net/ethernet/broadcom/bnx2x/ > > > scsi/esas2r/esas2r_init.c > > > not sure on reasoning behind the file splits in these drivers > > > but definitely looks like it we could just merge a few files > > > and let this be static + the compiler remove it neatly. > > > > > > vs 17 cases where the symbol is exported and more cleverness will > > > be needed. > > > > I don't see why exporting the symbol makes a difference at all, either > > it is needed in another file or it is not. > > Ah. My reasoning was that the purpose behind that patch set (letting > compiler remove the functions etc when unused) was not applicable in EXPORT* > cases. However, I'd neglected that the DEFINE_SIMPLE_DEV_PM_OPS() > macro is probably useful anyway as those cases would need CONFIG_PM* > guards if they want to remove the code when PM stuff isn't enabled. I agree with Arnd that including "static" in the DEFINE_UNIVERSAL_DEV_PM_OPS and DEFINE_SIMPLE_DEV_PM_OPS is not particularly useful. > > > > I think it would be more natural to not include 'static' in the macro, > > that is certainly what all other macros like this do, and it's still > > trivial to add 'static' manually, but impossible to remove it. > > IIRC there are other cases like this, but it was exactly this somewhat > unusual element that made me raise the question in the original discussion. > > Paul, over to you for reasoning. If we are going to change this > now is the time before they get significant use and we end up having > to add static to lots of places. So please feel free to submit a patch removing these "static" qualifiers from the macros in question or I will do that. Thanks!
