Is PPC 44x PIKA Warp board still relevant?
Hi Michael, Nick, I was wondering if PIKA Warp board still relevant. The reason for my question is that I am interested in dropping legacy gpio APIs, especially OF-specific ones, in favor of newer gpiod APIs, and arch/powerpc/platforms/44x/warp.c is one of few users of it. The code in question is supposed to turn off green led and flash red led in case of overheating, and is doing so by directly accessing GPIOs owned by led-gpio driver without requesting/allocating them. This is not really supported with gpiod API, and is not a good practice in general. Before I spend much time trying to implement a replacement without access to the hardware, I wonder if this board is in use at all, and if it is how important is the feature of flashing red led on critical temperature shutdown? Thanks. -- Dmitry
Re: [PATCH] powerpc/irq: Modernise inline assembly in irq_soft_mask_{set,return}
On Fri, Sep 23, 2022 at 05:15:43PM -0500, Segher Boessenkool wrote:
> On Sat, Sep 24, 2022 at 02:26:52AM +1000, Nicholas Piggin wrote:
> > I still don't see what clauses guarantees asm("%0" ::"r"(foo)) to give
> > 13. It doesn't say access via inline assembly is special,
>
> But it is. It is for all register variables, local and global. I agree
> this isn't documented clearly. For local register variables this is the
> *only* thing guaranteed; for global register vars there is more (it
> changes the ABI, there are safe/restore effects, that kind of thing).
I filed to improve the docs. Thanks for
bringing this to our attention!
Segher
Re: [PATCH] powerpc/irq: Modernise inline assembly in irq_soft_mask_{set,return}
On Sat, Sep 24, 2022 at 02:00:55PM +1000, Nicholas Piggin wrote: > On Sat Sep 24, 2022 at 8:15 AM AEST, Segher Boessenkool wrote: > > Never it is guaranteed that all accesses through this variable will use > > the register directly: this fundamentally cannot work on all archs, and > > also not at -O0. More in general it doesn't work if some basic > > optimisations are not done, be it because of a compiler deficiency, or a > > straight out bug, or maybe it is a conscious choice in some cases. > > Right, and we know better than to rely on a spec that is not 100% air > tight with no possibility of lawyering. This may be what the intention is, > it may be what gcc and clang do now, and everybody involved today agrees > with that interpretation. We still have to maintain the kernel tomorrow > though, so explicit r13 it must be. It has *always* been this way. Very old GCC (say, GCC < 3.x) tried to guarantee more, even, but that turned out to be untenable. But this is all in the distant past. I have no idea if clang implements the GCC C extensions correctly. If they don't it is just another compiler bug and they'll just have to fix it. The rules *are* airtight. But this does not mean you can assume random other stuff, adjacent or not :-P > > (Please use "n" instead of "i". Doesn't matter here, but it does in > > many other places.) > > What is the difference? Just "i" allows assmebly-time constants? "n" means "number": constant integers. "i" means "immediate": any constant. The address of a global variable is "i" but not "n" (in most ABIs, no -fPIC and such) for example. > How about "I"? that looks like it was made for it. Gives much better > errors. For PowerPC, "I" is a signed 16-bit number. "K" is unsigned 16-bit, and there are more as well. Just like for "n" you'll have to make sure the number you feed in will work in the assembler, and you'll get the same error message (but, as you say, for "I" in some cases the compiler will give errors already). It's otherwise only useful if you use e.g. "IL" as constraint, and then write "addi%e2 %0,%1,%2" for example, so the asm can generate "addis" insns. Such things aren't very often useful in internal asm. The main reason any of this exists is this is how GCC works internally; extended inline asm exposes a lot of that. Segher
Re: [PATCH 5.15 0/6] arm64: kexec_file: use more system keyrings to verify kernel image signature + dependencies
On Fri, Sep 23, 2022 at 09:16:50PM +0200, Michal Suchánek wrote:
> Hello,
>
> On Fri, Sep 23, 2022 at 03:03:36PM -0400, Mimi Zohar wrote:
> > On Fri, 2022-09-23 at 19:10 +0200, Michal Suchanek wrote:
> > > Hello,
> > >
> > > this is backport of commit 0d519cadf751
> > > ("arm64: kexec_file: use more system keyrings to verify kernel image
> > > signature")
> > > to table 5.15 tree including the preparatory patches.
> > >
> > > Some patches needed minor adjustment for context.
> >
> > In general when backporting this patch set, there should be a
> > dependency on backporting these commits as well. In this instance for
> > linux-5.15.y, they've already been backported.
> >
> > 543ce63b664e ("lockdown: Fix kexec lockdown bypass with ima policy")
AFAICT this is everywhere relevant, likely because it's considered a CVE
fix.
> > af16df54b89d ("ima: force signature verification when CONFIG_KEXEC_SIG is
> > configured")
This is missing in 5.4, and 5.4 is missing this prerequisite:
fd7af71be542 ("kexec: do not verify the signature without the lockdown or
mandatory signature")
>
> Thanks for bringing these up. It might be in general useful to backport
> these fixes as well.
>
> However, this patchset does one very specific thing: it lifts the x86
> kexec_file signature verification to arch-independent and uses it on
> arm64 to unify all features (and any existing warts) between EFI
> architectures.
>
> So unless I am missing something the fixes you pointed out are
> completely independent of this.
>
> Thanks
>
> Michal
Re: [PATCH 0/7] powerpc/85xx: p2020: Create one unified machine description
Hello! Any comments for these patches?
On Friday 19 August 2022 21:15:50 Pali Rohár wrote:
> This patch series unifies all P2020 boards and machine descriptions into
> one generic unified P2020 machine description. With this generic machine
> description, kernel can boot on any P2020-based board with correct DTS
> file.
>
> Tested on CZ.NIC Turris 1.1 board with has Freescale P2020 processor.
> Kernel during booting correctly detects P2020 and prints:
> [0.00] Using Freescale P2020 machine description
>
> Pali Rohár (7):
> powerpc/85xx: Mark mpc85xx_rdb_pic_init() as static
> powerpc/85xx: Mark mpc85xx_ds_pic_init() as static
> powerpc/85xx: p2020: Move all P2020 machine descriptions to p2020.c
> powerpc/85xx: p2020: Unify .setup_arch and .init_IRQ callbacks
> powerpc/85xx: p2020: Define just one machine description
> powerpc/85xx: p2020: Enable boards by new config option CONFIG_P2020
> powerpc: dts: turris1x.dts: Remove "fsl,P2020RDB-PC" compatible string
>
> arch/powerpc/boot/dts/turris1x.dts| 2 +-
> arch/powerpc/platforms/85xx/Kconfig | 22 ++-
> arch/powerpc/platforms/85xx/Makefile | 1 +
> arch/powerpc/platforms/85xx/mpc85xx_ds.c | 25 +--
> arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 46 +-
> .../platforms/85xx/{mpc85xx_ds.c => p2020.c} | 144 +++---
> 6 files changed, 75 insertions(+), 165 deletions(-)
> copy arch/powerpc/platforms/85xx/{mpc85xx_ds.c => p2020.c} (53%)
>
> --
> 2.20.1
>
Re: [PATCH v2] powerpc: Add support for early debugging via Serial 16550 console
Hello! Is something else needed for this v2 patch?
On Tuesday 23 August 2022 01:15:01 Pali Rohár wrote:
> Currently powerpc early debugging contains lot of platform specific
> options, but does not support standard UART / serial 16550 console.
>
> Later legacy_serial.c code supports registering UART as early debug console
> from device tree but it is not early during booting, but rather later after
> machine description code finishes.
>
> So for real early debugging via UART is current code unsuitable.
>
> Add support for new early debugging option CONFIG_PPC_EARLY_DEBUG_16550
> which enable Serial 16550 console on address defined by new option
> CONFIG_PPC_EARLY_DEBUG_16550_PHYSADDR and by stride by option
> CONFIG_PPC_EARLY_DEBUG_16550_STRIDE.
>
> With this change it is possible to debug powerpc machine descriptor code.
> For example this early debugging code can print on serial console also
> "No suitable machine description found" error which is done before
> legacy_serial.c code.
>
> Signed-off-by: Pali Rohár
> ---
> Changes in v2:
> * Move PPC_EARLY_DEBUG_16550 after PPC_EARLY_DEBUG_MEMCONS, so memcons stay
> default
> * Add missing dependency on PPC_UDBG_16550
> ---
> Tested on P2020 board. It allowed me do debug and implement this patch series:
> https://lore.kernel.org/linuxppc-dev/20220819191557.28116-1-p...@kernel.org/
> ---
> arch/powerpc/Kconfig.debug | 15 +++
> arch/powerpc/include/asm/udbg.h | 1 +
> arch/powerpc/kernel/udbg.c | 2 ++
> arch/powerpc/kernel/udbg_16550.c | 33
> 4 files changed, 51 insertions(+)
>
> diff --git a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kconfig.debug
> index 9f363c143d86..ad7238d28fa9 100644
> --- a/arch/powerpc/Kconfig.debug
> +++ b/arch/powerpc/Kconfig.debug
> @@ -283,6 +283,12 @@ config PPC_EARLY_DEBUG_MEMCONS
> This console provides input and output buffers stored within the
> kernel BSS and should be safe to select on any system. A debugger
> can then be used to read kernel output or send input to the console.
> +
> +config PPC_EARLY_DEBUG_16550
> + bool "Serial 16550"
> + depends on PPC_UDBG_16550
> + help
> + Select this to enable early debugging via Serial 16550 console
> endchoice
>
> config PPC_MEMCONS_OUTPUT_SIZE
> @@ -355,6 +361,15 @@ config PPC_EARLY_DEBUG_CPM_ADDR
> platform probing is done, all platforms selected must
> share the same address.
>
> +config PPC_EARLY_DEBUG_16550_PHYSADDR
> + hex "Early debug Serial 16550 physical address"
> + depends on PPC_EARLY_DEBUG_16550
> +
> +config PPC_EARLY_DEBUG_16550_STRIDE
> + int "Early debug Serial 16550 stride"
> + depends on PPC_EARLY_DEBUG_16550
> + default 1
> +
> config FAIL_IOMMU
> bool "Fault-injection capability for IOMMU"
> depends on FAULT_INJECTION
> diff --git a/arch/powerpc/include/asm/udbg.h b/arch/powerpc/include/asm/udbg.h
> index b4aa0d88ce2c..20b5a37ab772 100644
> --- a/arch/powerpc/include/asm/udbg.h
> +++ b/arch/powerpc/include/asm/udbg.h
> @@ -53,6 +53,7 @@ extern void __init udbg_init_ehv_bc(void);
> extern void __init udbg_init_ps3gelic(void);
> extern void __init udbg_init_debug_opal_raw(void);
> extern void __init udbg_init_debug_opal_hvsi(void);
> +extern void __init udbg_init_debug_16550(void);
>
> #endif /* __KERNEL__ */
> #endif /* _ASM_POWERPC_UDBG_H */
> diff --git a/arch/powerpc/kernel/udbg.c b/arch/powerpc/kernel/udbg.c
> index b1544b2f6321..92b3fc258d11 100644
> --- a/arch/powerpc/kernel/udbg.c
> +++ b/arch/powerpc/kernel/udbg.c
> @@ -67,6 +67,8 @@ void __init udbg_early_init(void)
> udbg_init_debug_opal_raw();
> #elif defined(CONFIG_PPC_EARLY_DEBUG_OPAL_HVSI)
> udbg_init_debug_opal_hvsi();
> +#elif defined(CONFIG_PPC_EARLY_DEBUG_16550)
> + udbg_init_debug_16550();
> #endif
>
> #ifdef CONFIG_PPC_EARLY_DEBUG
> diff --git a/arch/powerpc/kernel/udbg_16550.c
> b/arch/powerpc/kernel/udbg_16550.c
> index d3942de254c6..46f2d831d7c9 100644
> --- a/arch/powerpc/kernel/udbg_16550.c
> +++ b/arch/powerpc/kernel/udbg_16550.c
> @@ -8,6 +8,7 @@
> #include
> #include
> #include
> +#include
>
> extern u8 real_readb(volatile u8 __iomem *addr);
> extern void real_writeb(u8 data, volatile u8 __iomem *addr);
> @@ -335,3 +336,35 @@ void __init udbg_init_debug_microwatt(void)
> }
>
> #endif /* CONFIG_PPC_EARLY_DEBUG_MICROWATT */
> +
> +#ifdef CONFIG_PPC_EARLY_DEBUG_16550
> +
> +static void __iomem *udbg_uart_early_addr;
> +
> +void __init udbg_init_debug_16550(void)
> +{
> + udbg_uart_early_addr =
> early_ioremap(CONFIG_PPC_EARLY_DEBUG_16550_PHYSADDR, 0x1000);
> + udbg_uart_init_mmio(udbg_uart_early_addr,
> CONFIG_PPC_EARLY_DEBUG_16550_STRIDE);
> +}
> +
> +static int __init udbg_init_debug_16550_ioremap(void)
> +{
> + void __iomem *addr;
> +
> + if (!udbg_uart_early_addr)
> + return 0;
> +
> + addr = ioremap(CONFIG_PPC_EARLY_DEBUG_16550_PHYSADDR,
Re: [PATCH 5.15 0/6] arm64: kexec_file: use more system keyrings to verify kernel image signature + dependencies
On Sat, Sep 24, 2022 at 12:13:34PM +0200, Greg Kroah-Hartman wrote:
> On Sat, Sep 24, 2022 at 11:45:21AM +0200, Michal Suchánek wrote:
> > On Sat, Sep 24, 2022 at 11:19:19AM +0200, Greg Kroah-Hartman wrote:
> > > On Fri, Sep 23, 2022 at 07:10:28PM +0200, Michal Suchanek wrote:
> > > > Hello,
> > > >
> > > > this is backport of commit 0d519cadf751
> > > > ("arm64: kexec_file: use more system keyrings to verify kernel image
> > > > signature")
> > > > to table 5.15 tree including the preparatory patches.
> > >
> > > This feels to me like a new feature for arm64, one that has never worked
> > > before and you are just making it feature-parity with x86, right?
> > >
> > > Or is this a regression fix somewhere? Why is this needed in 5.15.y and
> > > why can't people who need this new feature just use a newer kernel
> > > version (5.19?)
> >
> > It's half-broken implementation of the kexec kernel verification. At the
> > time
> > it was implemented for arm64 we had the platform and secondary keyrings
> > and x86 was using them but on arm64 the initial implementation ignores
> > them.
>
> Ok, so it's something that never worked. Adding support to get it to
> work doesn't really fall into the stable kernel rules, right?
Not sure. It was defective, not using the facilities available at the
time correctly. Which translates to kernels that can be kexec'd on x86
failing to kexec on arm64 without any explanation (signed with same key,
built for the appropriate arch).
> Again, what's wrong with 5.19 for anyone who wants this? Who does want
> this?
Not sure, really.
The final patch was repeatedly backported to stable and failed to build
because the prerequisites were missing.
So this is a backport that includes the prerequisites for it to build.
If nobody wanted this why is it repeatedly backported generating the
failure messages?
Thanks
Michal
Re: [PATCH 5.15 0/6] arm64: kexec_file: use more system keyrings to verify kernel image signature + dependencies
On Sat, Sep 24, 2022 at 11:45:21AM +0200, Michal Suchánek wrote:
> On Sat, Sep 24, 2022 at 11:19:19AM +0200, Greg Kroah-Hartman wrote:
> > On Fri, Sep 23, 2022 at 07:10:28PM +0200, Michal Suchanek wrote:
> > > Hello,
> > >
> > > this is backport of commit 0d519cadf751
> > > ("arm64: kexec_file: use more system keyrings to verify kernel image
> > > signature")
> > > to table 5.15 tree including the preparatory patches.
> >
> > This feels to me like a new feature for arm64, one that has never worked
> > before and you are just making it feature-parity with x86, right?
> >
> > Or is this a regression fix somewhere? Why is this needed in 5.15.y and
> > why can't people who need this new feature just use a newer kernel
> > version (5.19?)
>
> It's half-broken implementation of the kexec kernel verification. At the time
> it was implemented for arm64 we had the platform and secondary keyrings
> and x86 was using them but on arm64 the initial implementation ignores
> them.
Ok, so it's something that never worked. Adding support to get it to
work doesn't really fall into the stable kernel rules, right?
Again, what's wrong with 5.19 for anyone who wants this? Who does want
this?
thanks,
greg k-h
Re: [PATCH 5.15 0/6] arm64: kexec_file: use more system keyrings to verify kernel image signature + dependencies
On Sat, Sep 24, 2022 at 11:19:19AM +0200, Greg Kroah-Hartman wrote:
> On Fri, Sep 23, 2022 at 07:10:28PM +0200, Michal Suchanek wrote:
> > Hello,
> >
> > this is backport of commit 0d519cadf751
> > ("arm64: kexec_file: use more system keyrings to verify kernel image
> > signature")
> > to table 5.15 tree including the preparatory patches.
>
> This feels to me like a new feature for arm64, one that has never worked
> before and you are just making it feature-parity with x86, right?
>
> Or is this a regression fix somewhere? Why is this needed in 5.15.y and
> why can't people who need this new feature just use a newer kernel
> version (5.19?)
It's half-broken implementation of the kexec kernel verification. At the time
it was implemented for arm64 we had the platform and secondary keyrings
and x86 was using them but on arm64 the initial implementation ignores
them.
Thanks
Michal
Re: [PATCH 5.15 0/6] arm64: kexec_file: use more system keyrings to verify kernel image signature + dependencies
On Fri, Sep 23, 2022 at 07:10:28PM +0200, Michal Suchanek wrote:
> Hello,
>
> this is backport of commit 0d519cadf751
> ("arm64: kexec_file: use more system keyrings to verify kernel image
> signature")
> to table 5.15 tree including the preparatory patches.
This feels to me like a new feature for arm64, one that has never worked
before and you are just making it feature-parity with x86, right?
Or is this a regression fix somewhere? Why is this needed in 5.15.y and
why can't people who need this new feature just use a newer kernel
version (5.19?)
thanks,
greg k-h
Re: [PATCH v6 4/8] phy: fsl: Add Lynx 10G SerDes driver
On 20-09-22, 16:23, Sean Anderson wrote: > This adds support for the Lynx 10G "SerDes" devices found on various NXP > QorIQ SoCs. There may be up to four SerDes devices on each SoC, each > supporting up to eight lanes. Protocol support for each SerDes is highly > heterogeneous, with each SoC typically having a totally different > selection of supported protocols for each lane. Additionally, the SerDes > devices on each SoC also have differing support. One SerDes will > typically support Ethernet on most lanes, while the other will typically > support PCIe on most lanes. > > There is wide hardware support for this SerDes. It is present on QorIQ > T-Series and Layerscape processors. Because each SoC typically has > specific instructions and exceptions for its SerDes, I have limited the > initial scope of this module to just the LS1046A and LS1088A. > Additionally, I have only added support for Ethernet protocols. There is > not a great need for dynamic reconfiguration for other protocols (except > perhaps for M.2 cards), so support for them may never be added. > > Nevertheless, I have tried to provide an obvious path for adding support > for other SoCs as well as other protocols. SATA just needs support for > configuring LNmSSCR0. PCIe may need to configure the equalization > registers. It also uses multiple lanes. I have tried to write the driver > with multi-lane support in mind, so there should not need to be any > large changes. Although there are 6 protocols supported, I have only > tested SGMII and XFI. The rest have been implemented as described in > the datasheet. Most of these protocols should work "as-is", but > 10GBASE-KR will need PCS support for link training. > > The PLLs are modeled as clocks proper. This lets us take advantage of > the existing clock infrastructure. I have not given the same treatment > to the per-lane clocks because they need to be programmed in-concert > with the rest of the lane settings. One tricky thing is that the VCO > (PLL) rate exceeds 2^32 (maxing out at around 5GHz). This will be a > problem on 32-bit platforms, since clock rates are stored as unsigned > longs. To work around this, the pll clock rate is generally treated in > units of kHz. > > The PLLs are configured rather interestingly. Instead of the usual direct > programming of the appropriate divisors, the input and output clock rates > are selected directly. Generally, the only restriction is that the input > and output must be integer multiples of each other. This suggests some kind > of internal look-up table. The datasheets generally list out the supported > combinations explicitly, and not all input/output combinations are > documented. I'm not sure if this is due to lack of support, or due to an > oversight. If this becomes an issue, then some combinations can be > blacklisted (or whitelisted). This may also be necessary for other SoCs > which have more stringent clock requirements. > > The general API call list for this PHY is documented under the driver-api > docs. I think this is rather standard, except that most drivers configure > the mode (protocol) at xlate-time. Unlike some other phys where e.g. PCIe > x4 will use 4 separate phys all configured for PCIe, this driver uses one > phy configured to use 4 lanes. This is because while the individual lanes > may be configured individually, the protocol selection acts on all lanes at > once. Additionally, the order which lanes should be configured in is > specified by the datasheet. To coordinate this, lanes are reserved in > phy_init, and released in phy_exit. > > This driver was written with reference to the LS1046A reference manual. > However, it was informed by reference manuals for all processors with > mEMACs, especially the T4240 (which appears to have a "maxed-out" > configuration). The earlier P-Series processors appear to be similar, but > have a different overall register layout (using "banks" instead of > separate SerDes). Perhaps this those use a "5G Lynx SerDes." > > Signed-off-by: Sean Anderson > --- > > Changes in v6: > - Update MAINTAINERS to include new files > - Include bitfield.h and slab.h to allow compilation on non-arm64 > arches. > - Depend on COMMON_CLK and either layerscape/ppc > > Changes in v5: > - Remove references to PHY_INTERFACE_MODE_1000BASEKX to allow this > series to be applied directly to linux/master. > - Add fsl,lynx-10g.h to MAINTAINERS > > Changes in v4: > - Rework all debug statements to remove use of __func__. Additional > information has been provided as necessary. > - Consider alternative parent rates in round_rate and not in set_rate. > Trying to modify out parent's rate in set_rate will deadlock. > - Explicitly perform a stop/reset sequence in set_rate. This way we > always ensure that the PLL is properly stopped. > - Set the power-down bit when disabling the PLL. We can do this now that > enable/disable aren't abused during the set rate sequence. > - Fix typos in QSGMII_OFFSET and
