Nathan Lynch <nath...@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-nath...@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-nath...@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?
