[PATCH v2 0/4] powerpc/rtas: exports and locking

[Nathan Lynch]

Nathan Lynch <nathanl at linux.ibm.com> writes:
> This series began as a single patch[1] to convert the RTAS subsystem's
> internal locks to raw spinlocks. The discussion of that patch
> identified opportunities to update a few aspects of the RTAS API, so
> the series begins with those and ends with a rebased version of the
> original patch.
>
> Changes since v1:
> - Unexport the singleton 'rtas' struct.
> - Remove lock and args fields from 'struct rtas_t', making them
>   private to the RTAS subsystem.
> - Convert all symbol exports in rtas.c to EXPORT_SYMBOL_GPL.
>
> [1] https://lore.kernel.org/linuxppc-dev/20230110044255.122616-1-nathanl@linux.ibm.com/
>
> Nathan Lynch (4):
>   powerpc/rtas: unexport 'rtas' symbol
>   powerpc/rtas: make all exports GPL
>   powerpc/rtas: remove lock and args fields from global rtas struct
>   powerpc/rtas: upgrade internal arch spinlocks
>
>  arch/powerpc/include/asm/rtas-types.h |   2 -
>  arch/powerpc/kernel/rtas.c            | 127 +++++++++++---------------
>  2 files changed, 55 insertions(+), 74 deletions(-)

Note this series conflicts with my earlier series "[PATCH v2 0/4] RTAS
function table and tracepoints":

https://lore.kernel.org/linuxppc-dev/20221212230154.851325-1-nathanl@linux.ibm.com/

I'll plan on rebasing the tracepoint series, which is more
disruptive/ambitious, on this one. Let me know if I should do
otherwise.

To be transparent, I have a fair amount of RTAS-oriented but otherwise
loosely related work in progress and I'm struggling to keep it organized
and establish a submission/review cadence. Having conflicting series
pending probably is not great :-(

Should I maintain a single stack of patches over time to avoid conflicts
like this, even though there may not be a unifying theme beyond it all
being generally RTAS-related?