linux/arch/powerpc/sysdev/xics, branch v6.3

powerpc/rtas: arch-wide function token lookup conversions

2023-02-13T11:35:03Z

With the tokens for all implemented RTAS functions now available via rtas_function_token(), which is optimal and safe for arbitrary contexts, there is no need to use rtas_token() or cache its result. Most conversions are trivial, but a few are worth describing in more detail: * Error injection token comparisons for lockdown purposes are consolidated into a simple predicate: token_is_restricted_errinjct(). * A couple of special cases in block_rtas_call() do not use rtas_token() but perform string comparisons against names in the function table. These are converted to compare against token values instead, which is logically equivalent but less expensive. * The lookup for the ibm,os-term token can be deferred until needed, instead of caching it at boot to avoid device tree traversal during panic. * Since rtas_function_token() accesses a read-only data structure without taking any locks, xmon's lookup of set-indicator can be performed as needed instead of cached at startup. Signed-off-by: Nathan Lynch Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20230125-b4-powerpc-rtas-queue-v3-20-26929c8cce78@linux.ibm.com

Revert "powerpc/rtas: Implement reentrant rtas call"

2022-09-14T12:43:13Z

At the time this was submitted by Leonardo, I confirmed -- or thought I had confirmed -- with PowerVM partition firmware development that the following RTAS functions: - ibm,get-xive - ibm,int-off - ibm,int-on - ibm,set-xive were safe to call on multiple CPUs simultaneously, not only with respect to themselves as indicated by PAPR, but with arbitrary other RTAS calls: https://lore.kernel.org/linuxppc-dev/875zcy2v8o.fsf@linux.ibm.com/ Recent discussion with firmware development makes it clear that this is not true, and that the code in commit b664db8e3f97 ("powerpc/rtas: Implement reentrant rtas call") is unsafe, likely explaining several strange bugs we've seen in internal testing involving DLPAR and LPM. These scenarios use ibm,configure-connector, whose internal state can be corrupted by the concurrent use of the "reentrant" functions, leading to symptoms like endless busy statuses from RTAS. Fixes: b664db8e3f97 ("powerpc/rtas: Implement reentrant rtas call") Cc: stable@vger.kernel.org # v5.8+ Signed-off-by: Nathan Lynch Reviewed-by: Laurent Dufour Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20220907220111.223267-1-nathanl@linux.ibm.com

powerpc/xics: Include missing header

2022-05-24T10:44:30Z

Include of_adresses.h to get of_iomap() prototype. Fixes: 86c38fec69a4 ("powerpc: Remove asm/prom.h from all files that don't need it") Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/f20a14be1a29fa0a9ebcfc5ebf05eb69c5120d10.1653370502.git.christophe.leroy@csgroup.eu

powerpc/xics: fix refcount leak in icp_opal_init()

2022-05-22T05:58:30Z

The of_find_compatible_node() function returns a node pointer with refcount incremented, use of_node_put() on it when done. Reported-by: Zeal Robot Signed-off-by: Lv Ruyi Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20220402013419.2410298-1-lv.ruyi@zte.com.cn

powerpc/kasan: Disable address sanitization in kexec paths

2022-05-22T05:58:29Z

The kexec code paths involve code that necessarily run in real mode, as CPUs are disabled and control is transferred to the new kernel. Disable address sanitization for the kexec code and the functions called in real mode on CPUs being disabled. [paulus@ozlabs.org: combined a few work-in-progress commits of Daniel's and wrote the commit message.] Signed-off-by: Daniel Axtens Signed-off-by: Paul Mackerras [mpe: Move pseries_machine_kexec() into kexec.c so setup.c can be instrumented] Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/YoTFSQ2TUSEaDdVC@cleo

powerpc: Add missing headers

2022-05-08T12:15:40Z

Don't inherit headers "by chances" from asm/prom.h, asm/mpc52xx.h, asm/pci.h etc... Include the needed headers, and remove asm/prom.h when it was needed exclusively for pulling necessary headers. Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/be8bdc934d152a7d8ee8d1a840d5596e2f7d85e0.1646767214.git.christophe.leroy@csgroup.eu

powerpc: Remove asm/prom.h from all files that don't need it

2022-05-08T12:15:04Z

Several files include asm/prom.h for no reason. Clean it up. Signed-off-by: Christophe Leroy [mpe: Drop change to prom_parse.c as reported by lkp@intel.com] Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/7c9b8fda63dcf63e1b28f43e7ebdb95182cbc286.1646767214.git.christophe.leroy@csgroup.eu

powerpc/sysdev: Add __init attribute to eligible functions

2021-12-23T11:33:12Z

Some files functions in 'arch/powerpc/sysdev' are deserving of an `__init` macro attribute. These functions are only called by other initialization functions and therefore should inherit the attribute. Also, change function declarations in header files to include `__init`. Signed-off-by: Nick Child Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20211216220035.605465-6-nick.child@ibm.com

powerpc/xics: Set the IRQ chip data for the ICS native backend

2021-09-15T12:05:53Z

The ICS native driver relies on the IRQ chip data to find the struct 'ics_native' describing the ICS controller but it was removed by commit 248af248a8f4 ("powerpc/xics: Rename the map handler in a check handler"). Revert this change to fix the Microwatt SoC platform. Fixes: 248af248a8f4 ("powerpc/xics: Rename the map handler in a check handler") Signed-off-by: Cédric Le Goater Tested-by: Gustavo Romero Reviewed-by: Joel Stanley Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210913134056.3761960-1-clg@kaod.org

powerpc: use IRQF_NO_DEBUG for IPIs

2021-08-10T13:15:01Z

There is no need to use the lockup detector ("noirqdebug") for IPIs. The ipistorm benchmark measures a ~10% improvement on high systems when this flag is set. Signed-off-by: Cédric Le Goater Reviewed-by: Thomas Gleixner Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210719130614.195886-1-clg@kaod.org