Thread (2 messages) 2 messages, 2 authors, 2025-11-21

Re: [PATCH v2 05/15] gpio: pxa: Use modern PM macros

From: Andy Shevchenko <hidden>
Date: 2025-11-21 09:20:15
Also in: linux-gpio, linux-omap, lkml

On Thu, Nov 20, 2025 at 09:48:30PM +0100, Robert Jarzmik wrote:
Jisheng Zhang [off-list ref] writes:
quoted
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 ...
quoted
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


Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help