[PATCH v2 05/15] gpio: pxa: Use modern PM macros
Andy Shevchenko
andriy.shevchenko at intel.com
Fri Nov 21 01:20:07 PST 2025
On Thu, Nov 20, 2025 at 09:48:30PM +0100, Robert Jarzmik wrote:
> Jisheng Zhang <jszhang at kernel.org> writes:
> > On Tue, Nov 18, 2025 at 11:03:41PM +0100, Robert Jarzmik wrote:
> >
> > hmm, each controller adds 16bytes, then even on 100 controller platforms
> > 1600bytes. 1600 Bytes/64MB ~= 0.238%. it's trival. And is there such
> > platform?
> Yes, actually most of them have around 64MB, at least the pxa25x and pxa27x.
> The pxa3xx might have more (thing 128MB, maybe 256MB).
> There are very old platforms, we're in 2003/2004 there ...
>
> > From another side, recently UP support is removed from the core sched,
> > that removing adds more .text and .data overhead, so if the users really
> > care about this kind of 16bytes, it means he(she) can't afford even the
> > 16Bytes overhead, then I bet he(she) the always SMP in core sched, so
> > why not stick with the old kernel? What do you think?
> I think I would go with Andy's proposal, decouple the changes :
> - keep your changes in the PM callbaks
> - remove your change (put back the ifdef) in the data structure
It can't be done like this, unfortunately.
Either we need to waste a pointer and kmalloc() overheads at runtime, or keep
these bytes for !PM cases.
Alternatively we can drop this change and simply add a comment explaining
the memory requirements and why we don't want to always waste those bytes.
Ideally would be good to have some kind of struct_group() macro that is
dependent on IS_ENABLED() case. It may help in many cases like this then.
--
With Best Regards,
Andy Shevchenko
More information about the linux-arm-kernel
mailing list