Re: [PATCH linux-next] powerpc: disable sanitizer in irq_soft_mask_set
Le 23/08/2022 à 03:43, Zhouyi Zhou a écrit :
> On Mon, Aug 22, 2022 at 2:04 PM Christophe Leroy
> wrote:
>>
>>
>>
>> Le 21/08/2022 à 03:00, Zhouyi Zhou a écrit :
>>> In ppc, compiler based sanitizer will generate instrument instructions
>>> around statement WRITE_ONCE(local_paca->irq_soft_mask, mask):
>>>
>>> 0xc0295cb0 <+0>: addis r2,r12,774
>>> 0xc0295cb4 <+4>: addir2,r2,16464
>>> 0xc0295cb8 <+8>: mflrr0
>>> 0xc0295cbc <+12>: bl 0xc008bb4c
>>> 0xc0295cc0 <+16>: mflrr0
>>> 0xc0295cc4 <+20>: std r31,-8(r1)
>>> 0xc0295cc8 <+24>: addir3,r13,2354
>>> 0xc0295ccc <+28>: mr r31,r13
>>> 0xc0295cd0 <+32>: std r0,16(r1)
>>> 0xc0295cd4 <+36>: stdur1,-48(r1)
>>> 0xc0295cd8 <+40>: bl 0xc0609b98 <__asan_store1+8>
>>> 0xc0295cdc <+44>: nop
>>> 0xc0295ce0 <+48>: li r9,1
>>> 0xc0295ce4 <+52>: stb r9,2354(r31)
>>> 0xc0295ce8 <+56>: addir1,r1,48
>>> 0xc0295cec <+60>: ld r0,16(r1)
>>> 0xc0295cf0 <+64>: ld r31,-8(r1)
>>> 0xc0295cf4 <+68>: mtlrr0
>>>
>>> If there is a context switch before "stb r9,2354(r31)", r31 may
>>> not equal to r13, in such case, irq soft mask will not work.
>>>
>>> This patch disable sanitizer in irq_soft_mask_set.
>>
>> Well spotted, thanks.
> Thank Christophe for reviewing my patch and your guidance!
>>
>> You should add:
>>
>> Fixes: ef5b570d3700 ("powerpc/irq: Don't open code irq_soft_mask helpers")
> OK, I will do it!
>>
>> By the way, I think the READ_ONCE() likely has the same issue so you
>> should fix irq_soft_mask_return() at the same time.
> Yes, after disassembling irq_soft_mask_return, she has the same issue
> as irq_soft_mask_set.
>
> In addition, I read hw_irq.h by naked eye to search for removed inline
> assembly one by one,
> I found another place that we could possible enhance (Thank Paul E.
> McKenny for teaching me use git blame ;-)):
> 077fc62b2b66a("powerpc/irq: remove inline assembly in hard_irq_disable macro")
> --- a/arch/powerpc/include/asm/hw_irq.h
> +++ b/arch/powerpc/include/asm/hw_irq.h
> @@ -282,9 +282,7 @@ static inline bool pmi_irq_pending(void)
> flags = irq_soft_mask_set_return(IRQS_ALL_DISABLED);\
> local_paca->irq_happened |= PACA_IRQ_HARD_DIS; \
> if (!arch_irqs_disabled_flags(flags)) { \
> - asm ("stdx %%r1, 0, %1 ;" \
> -: "=m" (local_paca->saved_r1) \
> -: "b" (_paca->saved_r1));\
> + WRITE_ONCE(local_paca->saved_r1, current_stack_pointer);\
> trace_hardirqs_off(); \
> } \
> } while(0)
> I wrap the macro hard_irq_disable into a test function and disassemble
> it, she has the above issue too:
> (gdb) disassemble test002
> Dump of assembler code for function test002:
...
> Could we rewrite this macro into a static inline function as
> irq_soft_mask_set does, and disable sanitizer for it?
Yes we could try to do that, hoping it will not bring too much troubles
with circular header inclusion.
Another possible approach could be to create a WRITE_ONCE_NOCHECK() more
or less similar to existing READ_ONCE_NOCHECK().
We could also change READ_ONCE_NOCHECK() to accept bytes size then use
it for irq_soft_mask_return() .
Christophe
Re: [PATCH] i2c: pasemi: Add IRQ support for Apple Silicon
Arminder Singh writes: > This is the first time I'm interacting with the Linux mailing lists, so > please don't eviscerate me *too much* if I get the formatting wrong. > Of course I'm always willing to take criticism and improve my formatting > in the future. > > This patch adds support for IRQs to the PASemi I2C controller driver. > This will allow for faster performing I2C transactions on Apple Silicon > hardware, as previously, the driver was forced to poll the SMSTA register > for a set amount of time. > > With this patchset the driver on Apple silicon hardware will instead wait > for an interrupt which will signal the completion of the I2C transaction. > The timeout value for this completion will be the same as the current > amount of time the I2C driver polls for. > > This will result in some performance improvement since the driver will be > waiting for less time than it does right now on Apple Silicon hardware. > > The patch right now will only enable IRQs for Apple Silicon I2C chips, > and only if it's able to successfully request the IRQ from the kernel. > > === Testing === > > This patch has been tested on both the mainline Linux kernel tree and > the Asahi branch (https://github.com/AsahiLinux/linux.git) on both an > M1 and M2 MacBook Air, and it compiles successfully as both a module and > built-in to the kernel itself. The patch in both trees successfully boots > to userspace without any hitch. > > I do not have PASemi hardware on hand unfortunately, so I'm unable to test > the impact of this patch on old PASemi hardware. This is also why I've > elected to do the IRQ request and enablement on the Apple platform driver > and not in the common file, as I'm not sure if PASemi hardware supports > IRQs. I've added Darren and Christian to Cc, they have helped with PASemi development and testing in the past, and may be able to help test this series on PASemi hardware. cheers
Re: [PATCH linux-next] powerpc: disable sanitizer in irq_soft_mask_set
On Mon, Aug 22, 2022 at 2:04 PM Christophe Leroy
wrote:
>
>
>
> Le 21/08/2022 à 03:00, Zhouyi Zhou a écrit :
> > In ppc, compiler based sanitizer will generate instrument instructions
> > around statement WRITE_ONCE(local_paca->irq_soft_mask, mask):
> >
> > 0xc0295cb0 <+0>: addis r2,r12,774
> > 0xc0295cb4 <+4>: addir2,r2,16464
> > 0xc0295cb8 <+8>: mflrr0
> > 0xc0295cbc <+12>: bl 0xc008bb4c
> > 0xc0295cc0 <+16>: mflrr0
> > 0xc0295cc4 <+20>: std r31,-8(r1)
> > 0xc0295cc8 <+24>: addir3,r13,2354
> > 0xc0295ccc <+28>: mr r31,r13
> > 0xc0295cd0 <+32>: std r0,16(r1)
> > 0xc0295cd4 <+36>: stdur1,-48(r1)
> > 0xc0295cd8 <+40>: bl 0xc0609b98 <__asan_store1+8>
> > 0xc0295cdc <+44>: nop
> > 0xc0295ce0 <+48>: li r9,1
> > 0xc0295ce4 <+52>: stb r9,2354(r31)
> > 0xc0295ce8 <+56>: addir1,r1,48
> > 0xc0295cec <+60>: ld r0,16(r1)
> > 0xc0295cf0 <+64>: ld r31,-8(r1)
> > 0xc0295cf4 <+68>: mtlrr0
> >
> > If there is a context switch before "stb r9,2354(r31)", r31 may
> > not equal to r13, in such case, irq soft mask will not work.
> >
> > This patch disable sanitizer in irq_soft_mask_set.
>
> Well spotted, thanks.
Thank Christophe for reviewing my patch and your guidance!
>
> You should add:
>
> Fixes: ef5b570d3700 ("powerpc/irq: Don't open code irq_soft_mask helpers")
OK, I will do it!
>
> By the way, I think the READ_ONCE() likely has the same issue so you
> should fix irq_soft_mask_return() at the same time.
Yes, after disassembling irq_soft_mask_return, she has the same issue
as irq_soft_mask_set.
In addition, I read hw_irq.h by naked eye to search for removed inline
assembly one by one,
I found another place that we could possible enhance (Thank Paul E.
McKenny for teaching me use git blame ;-)):
077fc62b2b66a("powerpc/irq: remove inline assembly in hard_irq_disable macro")
--- a/arch/powerpc/include/asm/hw_irq.h
+++ b/arch/powerpc/include/asm/hw_irq.h
@@ -282,9 +282,7 @@ static inline bool pmi_irq_pending(void)
flags = irq_soft_mask_set_return(IRQS_ALL_DISABLED);\
local_paca->irq_happened |= PACA_IRQ_HARD_DIS; \
if (!arch_irqs_disabled_flags(flags)) { \
- asm ("stdx %%r1, 0, %1 ;" \
-: "=m" (local_paca->saved_r1) \
-: "b" (_paca->saved_r1));\
+ WRITE_ONCE(local_paca->saved_r1, current_stack_pointer);\
trace_hardirqs_off(); \
} \
} while(0)
I wrap the macro hard_irq_disable into a test function and disassemble
it, she has the above issue too:
(gdb) disassemble test002
Dump of assembler code for function test002:
0xc0295db0 <+0>:addis r2,r12,774
0xc0295db4 <+4>:addir2,r2,16464
0xc0295db8 <+8>:mflrr0
0xc0295dbc <+12>:bl 0xc008bacc
0xc0295dc0 <+16>:mflrr0
0xc0295dc4 <+20>:std r30,-16(r1)
0xc0295dc8 <+24>:std r31,-8(r1)
0xc0295dcc <+28>:li r9,2
0xc0295dd0 <+32>:std r0,16(r1)
0xc0295dd4 <+36>:stdur1,-48(r1)
0xc0295dd8 <+40>:mtmsrd r9,1
0xc0295ddc <+44>:addir3,r13,2354
0xc0295de0 <+48>:mr r31,r13
0xc0295de4 <+52>:bl 0xc0609838 <__asan_load1+8>
0xc0295de8 <+56>:nop
0xc0295dec <+60>:li r3,3
0xc0295df0 <+64>:lbz r30,2354(r31)
0xc0295df4 <+68>:bl 0xc028de90
0xc0295df8 <+72>:mr r31,r13
0xc0295dfc <+76>:addir3,r13,2355
0xc0295e00 <+80>:bl 0xc0609838 <__asan_load1+8>
0xc0295e04 <+84>:nop
0xc0295e08 <+88>:lbz r9,2355(r31)
0xc0295e0c <+92>:andi. r10,r30,1
0xc0295e10 <+96>:ori r9,r9,1
0xc0295e14 <+100>:stb r9,2355(r31)
0xc0295e18 <+104>:bne 0xc0295e30
0xc0295e1c <+108>:mr r30,r1
0xc0295e20 <+112>:addir3,r31,2328
0xc0295e24 <+116>:bl 0xc0609dd8 <__asan_store8+8>
0xc0295e28 <+120>:nop
0xc0295e2c <+124>:std r30,2328(r31)
0xc0295e30 <+128>:addir1,r1,48
0xc0295e34 <+132>:ld r0,16(r1)
0xc0295e38 <+136>:ld r30,-16(r1)
0xc0295e3c <+140>:ld r31,-8(r1)
0xc0295e40 <+144>:mtlrr0
Re: [PATCH] net: move from strlcpy with unused retval to strscpy
On Thu, 18 Aug 2022 23:00:34 +0200 Wolfram Sang wrote: > 261 files changed, 568 insertions(+), 568 deletions(-) Unfortunately looks like patchwork was unable to ingest this change :( Not sure why. Would you mind splitting it into 3 chunks - wireless, ethernet, everything else, and resending? Let's see if that'll be small enough..
[PATCH] powerpc: udbg: Remove extern function prototypes
'extern' keywork is pointless and deprecated for function prototypes. Signed-off-by: Pali Rohár Suggested-by: Gabriel Paubert --- Depends on patch: https://lore.kernel.org/linuxppc-dev/20220819211254.22192-1-p...@kernel.org/ --- arch/powerpc/include/asm/udbg.h | 56 - 1 file changed, 28 insertions(+), 28 deletions(-) diff --git a/arch/powerpc/include/asm/udbg.h b/arch/powerpc/include/asm/udbg.h index 20b5a37ab772..2d74b264b326 100644 --- a/arch/powerpc/include/asm/udbg.h +++ b/arch/powerpc/include/asm/udbg.h @@ -15,13 +15,13 @@ extern void (*udbg_flush)(void); extern int (*udbg_getc)(void); extern int (*udbg_getc_poll)(void); -extern void udbg_puts(const char *s); -extern int udbg_write(const char *s, int n); +void udbg_puts(const char *s); +int udbg_write(const char *s, int n); -extern void register_early_udbg_console(void); -extern void udbg_printf(const char *fmt, ...) +void register_early_udbg_console(void); +void udbg_printf(const char *fmt, ...) __attribute__ ((format (printf, 1, 2))); -extern void udbg_progress(char *s, unsigned short hex); +void udbg_progress(char *s, unsigned short hex); void __init udbg_uart_init_mmio(void __iomem *addr, unsigned int stride); void __init udbg_uart_init_pio(unsigned long port, unsigned int stride); @@ -31,29 +31,29 @@ unsigned int __init udbg_probe_uart_speed(unsigned int clock); struct device_node; void __init udbg_scc_init(int force_scc); -extern int udbg_adb_init(int force_btext); -extern void udbg_adb_init_early(void); - -extern void __init udbg_early_init(void); -extern void __init udbg_init_debug_lpar(void); -extern void __init udbg_init_debug_lpar_hvsi(void); -extern void __init udbg_init_pmac_realmode(void); -extern void __init udbg_init_maple_realmode(void); -extern void __init udbg_init_pas_realmode(void); -extern void __init udbg_init_rtas_panel(void); -extern void __init udbg_init_rtas_console(void); -extern void __init udbg_init_debug_beat(void); -extern void __init udbg_init_btext(void); -extern void __init udbg_init_44x_as1(void); -extern void __init udbg_init_40x_realmode(void); -extern void __init udbg_init_cpm(void); -extern void __init udbg_init_usbgecko(void); -extern void __init udbg_init_memcons(void); -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); +int udbg_adb_init(int force_btext); +void udbg_adb_init_early(void); + +void __init udbg_early_init(void); +void __init udbg_init_debug_lpar(void); +void __init udbg_init_debug_lpar_hvsi(void); +void __init udbg_init_pmac_realmode(void); +void __init udbg_init_maple_realmode(void); +void __init udbg_init_pas_realmode(void); +void __init udbg_init_rtas_panel(void); +void __init udbg_init_rtas_console(void); +void __init udbg_init_debug_beat(void); +void __init udbg_init_btext(void); +void __init udbg_init_44x_as1(void); +void __init udbg_init_40x_realmode(void); +void __init udbg_init_cpm(void); +void __init udbg_init_usbgecko(void); +void __init udbg_init_memcons(void); +void __init udbg_init_ehv_bc(void); +void __init udbg_init_ps3gelic(void); +void __init udbg_init_debug_opal_raw(void); +void __init udbg_init_debug_opal_hvsi(void); +void __init udbg_init_debug_16550(void); #endif /* __KERNEL__ */ #endif /* _ASM_POWERPC_UDBG_H */ -- 2.20.1
[PATCH v2] powerpc: Add support for early debugging via Serial 16550 console
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, 0x1000);
+ if (WARN_ON(!addr))
+ return -ENOMEM;
+
+ udbg_uart_init_mmio(addr, CONFIG_PPC_EARLY_DEBUG_16550_STRIDE);
+ early_iounmap(udbg_uart_early_addr, 0x1000);
+ udbg_uart_early_addr = NULL;
+
+ return 0;
+}
+
+early_initcall(udbg_init_debug_16550_ioremap);
+
+#endif /*
[PATCH 4/5] ASoC: fsl: fsl-utils: remove useless assignment
cppcheck warning:
sound/soc/fsl/fsl_utils.c:127:10: style: Variable 'ret' is assigned a
value that is never used. [unreadVariable]
int ret = 0;
^
Signed-off-by: Pierre-Louis Bossart
Reviewed-by: Bard Liao
Reviewed-by: Kai Vehmanen
Reviewed-by: Chao Song
---
sound/soc/fsl/fsl_utils.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/fsl/fsl_utils.c b/sound/soc/fsl/fsl_utils.c
index d0fc430f7033d..a5ab27c2f711c 100644
--- a/sound/soc/fsl/fsl_utils.c
+++ b/sound/soc/fsl/fsl_utils.c
@@ -124,7 +124,7 @@ void fsl_asoc_reparent_pll_clocks(struct device *dev,
struct clk *clk,
{
struct clk *p, *pll = NULL, *npll = NULL;
bool reparent = false;
- int ret = 0;
+ int ret;
if (!clk || !pll8k_clk || !pll11k_clk)
return;
--
2.34.1
Re: [PATCH] powerpc/85xx: DTS: Add CPLD definitions for P1021RDB Combo Board CPL Design
On Monday 22 August 2022 12:00:56 Rob Herring wrote:
> On Fri, Aug 19, 2022 at 10:44:33AM +0200, Pali Rohár wrote:
> > P1021RDB Combo Board CPLD Design is used on following Freescale boards:
> > P1021RDB-PC, P1020RDB-PD, P1020MBG-PC, P1020UTM-PC and P2020RDB-PCA.
> >
> > Add CPLD definitions for all these boards for which already exist DTS file.
> >
> > CPLD has bank size 128kB, it is connected via CS3 on LBC and mapped to
> > memory range 0xFFA0~0xFFA1.
> >
> > As CPLD firmware is common on all these boards, use just one compatible
> > string "fsl,p1021rdb-pc-cpld".
> >
> > In some DTS files is CPLD already defined, but definition is either
> > incomplete or wrong. So fix it.
> >
> > All these boards have via CPLD connected max6370 watchdog at offset 0x2
> > with GPIO 11, status led at offset 0x8 and reset controller at offset 0xd.
> > Additionally P1020MBG-PC and P1020RDB-PD boards have FXO led at offset 0x9
> > and FXS leds at offset 0xa.
> >
> > Signed-off-by: Pali Rohár
> > ---
> > arch/powerpc/boot/dts/fsl/p1020mbg-pc.dtsi| 92 +++
> > arch/powerpc/boot/dts/fsl/p1020mbg-pc_32b.dts | 6 +-
> > arch/powerpc/boot/dts/fsl/p1020mbg-pc_36b.dts | 6 +-
> > arch/powerpc/boot/dts/fsl/p1020rdb-pd.dts | 44 +++--
> > arch/powerpc/boot/dts/fsl/p1020utm-pc.dtsi| 37
> > arch/powerpc/boot/dts/fsl/p1020utm-pc_32b.dts | 4 +-
> > arch/powerpc/boot/dts/fsl/p1020utm-pc_36b.dts | 4 +-
> > arch/powerpc/boot/dts/fsl/p1021rdb-pc.dtsi| 37
> > arch/powerpc/boot/dts/fsl/p1021rdb-pc_32b.dts | 5 +-
> > arch/powerpc/boot/dts/fsl/p1021rdb-pc_36b.dts | 5 +-
> > arch/powerpc/boot/dts/fsl/p2020rdb-pc.dtsi| 33 ++-
> > 11 files changed, 251 insertions(+), 22 deletions(-)
> >
> > diff --git a/arch/powerpc/boot/dts/fsl/p1020mbg-pc.dtsi
> > b/arch/powerpc/boot/dts/fsl/p1020mbg-pc.dtsi
> > index a24699cfea9c..c73996dcd809 100644
> > --- a/arch/powerpc/boot/dts/fsl/p1020mbg-pc.dtsi
> > +++ b/arch/powerpc/boot/dts/fsl/p1020mbg-pc.dtsi
> > @@ -83,6 +83,95 @@
> > compatible = "vitesse-7385";
> > reg = <0x2 0x0 0x2>;
> > };
> > +
> > + cpld@3,0 {
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + compatible = "fsl,p1021rdb-pc-cpld", "simple-bus", "syscon";
> > + reg = <0x3 0x0 0x2>;
> > + ranges = <0x0 0x3 0x0 0x2>;
> > +
> > + watchdog@2 {
> > + compatible = "maxim,max6370";
> > + reg = <0x2 0x1>;
> > + gpios = < 11 1>;
> > + };
> > +
> > + led@8 {
>
> The register-bit-led schema says this should be 'led@8,0'. Did you
> run 'dtbs_check'?
No, it does not work and I lost interest to trying setup machine for it again.
> But that's going to conflict with what simple-bus schema says.
Another reason why not try it again. Lot of schemas says that are in
conflict, nobody understand it and when I ask how to do it, I just get
silence or answer which does not work on the real hw. And if there is
some schema error message then it looks like it was generated by random
word generator.
> I don't
> know that 'simple-bus' is really appropriate here. The CPLD isn't really
> just a bus. 'simple-mfd' is what's more commonly used with 'syscon'.
Sorry, I do not understand those schemas anymore. And based on previous
failures, I'm not going to try it again.
It is a _bus_ and it was tested that it works as a bus with more
existing drivers.
> > + compatible = "register-bit-led";
> > + reg = <0x8 0x1>;
> > + offset = <0x8>;
> > + mask = <0x1>;
> > + active-low;
> > + default-state = "keep";
> > + label = "status";
> > + function = "status";
> > + color = <6>; /* LED_COLOR_ID_YELLOW */
> > + };
>
Re: [PATCH v7 6/6] tpm/kexec: Duplicate TPM measurement log in of-tree for kexec
On Fri, 12 Aug 2022 12:43:05 -0400, Stefan Berger wrote: > The memory area of the TPM measurement log is currently not properly > duplicated for carrying it across kexec when an Open Firmware > Devicetree is used. Therefore, the contents of the log get corrupted. > Fix this for the kexec_file_load() syscall by allocating a buffer and > copying the contents of the existing log into it. The new buffer is > preserved across the kexec and a pointer to it is available when the new > kernel is started. To achieve this, store the allocated buffer's address > in the flattened device tree (fdt) under the name linux,tpm-kexec-buffer > and search for this entry early in the kernel startup before the TPM > subsystem starts up. Adjust the pointer in the of-tree stored under > linux,sml-base to point to this buffer holding the preserved log. The TPM > driver can then read the base address from this entry when making the log > available. Invalidate the log by removing 'linux,sml-base' from the > devicetree if anything goes wrong with updating the buffer. > > Use subsys_initcall() to call the function to restore the buffer even if > the TPM subsystem or driver are not used. This allows the buffer to be > carried across the next kexec without involvement of the TPM subsystem > and ensures a valid buffer pointed to by the of-tree. > > Use the subsys_initcall(), rather than an ealier initcall, since > page_is_ram() in get_kexec_buffer() only starts working at this stage. > > Signed-off-by: Stefan Berger > Cc: Rob Herring > Cc: Frank Rowand > Cc: Eric Biederman > Tested-by: Nageswara R Sastry > > --- > v6: > - Define prototype for tpm_add_kexec_buffer under same config options >as drivers/of/kexec.c is compiled, provide inline function otherwise. >(kernel test robot) > > v4: > - Added #include due to parisc > - Use phys_addr_t for physical address rather than void * > - Remove linux,sml-base if the buffer cannot be updated after a kexec > - Added __init to functions where possible > --- > drivers/of/kexec.c| 216 +- > include/linux/kexec.h | 6 ++ > include/linux/of.h| 9 +- > kernel/kexec_file.c | 6 ++ > 4 files changed, 234 insertions(+), 3 deletions(-) > Reviewed-by: Rob Herring
Re: [PATCH net-next v4 2/8] dt-bindings: net: fman: Add additional interface properties
On Thu, 04 Aug 2022 15:46:59 -0400, Sean Anderson wrote: > At the moment, mEMACs are configured almost completely based on the > phy-connection-type. That is, if the phy interface is RGMII, it assumed > that RGMII is supported. For some interfaces, it is assumed that the > RCW/bootloader has set up the SerDes properly. This is generally OK, but > restricts runtime reconfiguration. The actual link state is never > reported. > > To address these shortcomings, the driver will need additional > information. First, it needs to know how to access the PCS/PMAs (in > order to configure them and get the link status). The SGMII PCS/PMA is > the only currently-described PCS/PMA. Add the XFI and QSGMII PCS/PMAs as > well. The XFI (and 10GBASE-KR) PCS/PMA is a c45 "phy" which sits on the > same MDIO bus as SGMII PCS/PMA. By default they will have conflicting > addresses, but they are also not enabled at the same time by default. > Therefore, we can let the XFI PCS/PMA be the default when > phy-connection-type is xgmii. This will allow for > backwards-compatibility. > > QSGMII, however, cannot work with the current binding. This is because > the QSGMII PCS/PMAs are only present on one MAC's MDIO bus. At the > moment this is worked around by having every MAC write to the PCS/PMA > addresses (without checking if they are present). This only works if > each MAC has the same configuration, and only if we don't need to know > the status. Because the QSGMII PCS/PMA will typically be located on a > different MDIO bus than the MAC's SGMII PCS/PMA, there is no fallback > for the QSGMII PCS/PMA. > > Signed-off-by: Sean Anderson > --- > > (no changes since v3) > > Changes in v3: > - Add vendor prefix 'fsl,' to rgmii and mii properties. > - Set maxItems for pcs-names > - Remove phy-* properties from example because dt-schema complains and I > can't be bothered to figure out how to make it work. > - Add pcs-handle as a preferred version of pcsphy-handle > - Deprecate pcsphy-handle > - Remove mii/rmii properties > > Changes in v2: > - Better document how we select which PCS to use in the default case > > .../bindings/net/fsl,fman-dtsec.yaml | 53 ++- > .../devicetree/bindings/net/fsl-fman.txt | 5 +- > 2 files changed, 43 insertions(+), 15 deletions(-) > Reviewed-by: Rob Herring
Re: [PATCH] powerpc/85xx: DTS: Add CPLD definitions for P1021RDB Combo Board CPL Design
On Fri, Aug 19, 2022 at 10:44:33AM +0200, Pali Rohár wrote:
> P1021RDB Combo Board CPLD Design is used on following Freescale boards:
> P1021RDB-PC, P1020RDB-PD, P1020MBG-PC, P1020UTM-PC and P2020RDB-PCA.
>
> Add CPLD definitions for all these boards for which already exist DTS file.
>
> CPLD has bank size 128kB, it is connected via CS3 on LBC and mapped to
> memory range 0xFFA0~0xFFA1.
>
> As CPLD firmware is common on all these boards, use just one compatible
> string "fsl,p1021rdb-pc-cpld".
>
> In some DTS files is CPLD already defined, but definition is either
> incomplete or wrong. So fix it.
>
> All these boards have via CPLD connected max6370 watchdog at offset 0x2
> with GPIO 11, status led at offset 0x8 and reset controller at offset 0xd.
> Additionally P1020MBG-PC and P1020RDB-PD boards have FXO led at offset 0x9
> and FXS leds at offset 0xa.
>
> Signed-off-by: Pali Rohár
> ---
> arch/powerpc/boot/dts/fsl/p1020mbg-pc.dtsi| 92 +++
> arch/powerpc/boot/dts/fsl/p1020mbg-pc_32b.dts | 6 +-
> arch/powerpc/boot/dts/fsl/p1020mbg-pc_36b.dts | 6 +-
> arch/powerpc/boot/dts/fsl/p1020rdb-pd.dts | 44 +++--
> arch/powerpc/boot/dts/fsl/p1020utm-pc.dtsi| 37
> arch/powerpc/boot/dts/fsl/p1020utm-pc_32b.dts | 4 +-
> arch/powerpc/boot/dts/fsl/p1020utm-pc_36b.dts | 4 +-
> arch/powerpc/boot/dts/fsl/p1021rdb-pc.dtsi| 37
> arch/powerpc/boot/dts/fsl/p1021rdb-pc_32b.dts | 5 +-
> arch/powerpc/boot/dts/fsl/p1021rdb-pc_36b.dts | 5 +-
> arch/powerpc/boot/dts/fsl/p2020rdb-pc.dtsi| 33 ++-
> 11 files changed, 251 insertions(+), 22 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/fsl/p1020mbg-pc.dtsi
> b/arch/powerpc/boot/dts/fsl/p1020mbg-pc.dtsi
> index a24699cfea9c..c73996dcd809 100644
> --- a/arch/powerpc/boot/dts/fsl/p1020mbg-pc.dtsi
> +++ b/arch/powerpc/boot/dts/fsl/p1020mbg-pc.dtsi
> @@ -83,6 +83,95 @@
> compatible = "vitesse-7385";
> reg = <0x2 0x0 0x2>;
> };
> +
> + cpld@3,0 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "fsl,p1021rdb-pc-cpld", "simple-bus", "syscon";
> + reg = <0x3 0x0 0x2>;
> + ranges = <0x0 0x3 0x0 0x2>;
> +
> + watchdog@2 {
> + compatible = "maxim,max6370";
> + reg = <0x2 0x1>;
> + gpios = < 11 1>;
> + };
> +
> + led@8 {
The register-bit-led schema says this should be 'led@8,0'. Did you
run 'dtbs_check'?
But that's going to conflict with what simple-bus schema says. I don't
know that 'simple-bus' is really appropriate here. The CPLD isn't really
just a bus. 'simple-mfd' is what's more commonly used with 'syscon'.
> + compatible = "register-bit-led";
> + reg = <0x8 0x1>;
> + offset = <0x8>;
> + mask = <0x1>;
> + active-low;
> + default-state = "keep";
> + label = "status";
> + function = "status";
> + color = <6>; /* LED_COLOR_ID_YELLOW */
> + };
Re: [PATCH] powerpc: Add support for early debugging via Serial 16550 console
On Mon, Aug 22, 2022 at 05:33:35PM +0200, Pali Rohár wrote: > On Monday 22 August 2022 14:25:57 Christophe Leroy wrote: > > Le 19/08/2022 à 23:12, Pali Rohár a écrit : > > > 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 > > > --- > > > 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/ > > > > Build failure if I select it on mpc885_ads_defconfig : > > > >LD vmlinux.o > >MODPOST vmlinux.symvers > >MODINFO modules.builtin.modinfo > >GEN modules.builtin > >CC .vmlinux.export.o > >LD .tmp_vmlinux.kallsyms1 > > powerpc64-linux-ld: arch/powerpc/kernel/udbg.o: in function > > `udbg_early_init': > > /home/chleroy/linux-powerpc/arch/powerpc/kernel/udbg.c:71: undefined > > reference to `udbg_init_debug_16550' > > > > > > > > > --- > > > arch/powerpc/Kconfig.debug | 14 ++ > > > arch/powerpc/include/asm/udbg.h | 1 + > > > arch/powerpc/kernel/udbg.c | 2 ++ > > > arch/powerpc/kernel/udbg_16550.c | 33 > > > 4 files changed, 50 insertions(+) > > > > > > diff --git a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kconfig.debug > > > index 9f363c143d86..a4e7d90a45d2 100644 > > > --- a/arch/powerpc/Kconfig.debug > > > +++ b/arch/powerpc/Kconfig.debug > > > @@ -276,6 +276,11 @@ config PPC_EARLY_DEBUG_OPAL_HVSI > > > Select this to enable early debugging for the PowerNV platform > > > using an "hvsi" console > > > > > > +config PPC_EARLY_DEBUG_16550 > > > + bool "Serial 16550" > > > + help > > > + Select this to enable early debugging via Serial 16550 console > > > + > > > > Putting it before EARLY_DEBUG_MEMCONS means that configs that were > > previously selectiong EARLY_DEBUG_MEMCONS will now select > > EARLY_DEBUG_16550 instead. > > > > Add a dependency to PPC_UDBG_16550 to avoid the build failure I mentionned ? > > Yea, there is really missing dependency. I will fix it. > > > > config PPC_EARLY_DEBUG_MEMCONS > > > bool "In memory console" > > > help > > > @@ -355,6 +360,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 > > > > A default value is necessary here to avoid prompts during defconfig builds. > > > > > + > > > +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); > > > > 'extern' keywork is pointless and deprecated for function prototypes, > > please don't add new ones. > > I used extern keyword to follow existing coding style. In this case it's better to remove existing extern specifications in the surrounding lines. Increasing a bit the footprint of the patch is justified, and does not significantly increase the risk of conflicts with other patches, unlike the gratuitous churn we see sometimes. Gabriel > > > Checkpatch reports: > > > > CHECK: extern prototypes should be avoided in .h files > > #77: FILE: arch/powerpc/include/asm/udbg.h:56: > > +extern void __init
Re: [PATCH v3 1/4] Make place for common balloon code
On Aug 22, 2022, at 4:37 AM, Alexander Atanasov wrote: > mm/balloon_compaction.c -> mm/balloon.c > File already contains code that is common along balloon > drivers so rename it to reflect its contents. > > include/linux/balloon_compaction.h -> include/linux/balloon.h > Remove it from files which do not actually use it. > Drop externs from function delcarations. > > Signed-off-by: Alexander Atanasov Makes so much sense. Acked-by: Nadav Amit
Re: [PATCH] powerpc: Add support for early debugging via Serial 16550 console
On Monday 22 August 2022 14:25:57 Christophe Leroy wrote: > Le 19/08/2022 à 23:12, Pali Rohár a écrit : > > 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 > > --- > > 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/ > > Build failure if I select it on mpc885_ads_defconfig : > >LD vmlinux.o >MODPOST vmlinux.symvers >MODINFO modules.builtin.modinfo >GEN modules.builtin >CC .vmlinux.export.o >LD .tmp_vmlinux.kallsyms1 > powerpc64-linux-ld: arch/powerpc/kernel/udbg.o: in function > `udbg_early_init': > /home/chleroy/linux-powerpc/arch/powerpc/kernel/udbg.c:71: undefined > reference to `udbg_init_debug_16550' > > > > > --- > > arch/powerpc/Kconfig.debug | 14 ++ > > arch/powerpc/include/asm/udbg.h | 1 + > > arch/powerpc/kernel/udbg.c | 2 ++ > > arch/powerpc/kernel/udbg_16550.c | 33 > > 4 files changed, 50 insertions(+) > > > > diff --git a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kconfig.debug > > index 9f363c143d86..a4e7d90a45d2 100644 > > --- a/arch/powerpc/Kconfig.debug > > +++ b/arch/powerpc/Kconfig.debug > > @@ -276,6 +276,11 @@ config PPC_EARLY_DEBUG_OPAL_HVSI > > Select this to enable early debugging for the PowerNV platform > > using an "hvsi" console > > > > +config PPC_EARLY_DEBUG_16550 > > + bool "Serial 16550" > > + help > > + Select this to enable early debugging via Serial 16550 console > > + > > Putting it before EARLY_DEBUG_MEMCONS means that configs that were > previously selectiong EARLY_DEBUG_MEMCONS will now select > EARLY_DEBUG_16550 instead. > > Add a dependency to PPC_UDBG_16550 to avoid the build failure I mentionned ? Yea, there is really missing dependency. I will fix it. > > config PPC_EARLY_DEBUG_MEMCONS > > bool "In memory console" > > help > > @@ -355,6 +360,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 > > A default value is necessary here to avoid prompts during defconfig builds. > > > + > > +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); > > 'extern' keywork is pointless and deprecated for function prototypes, > please don't add new ones. I used extern keyword to follow existing coding style. > Checkpatch reports: > > CHECK: extern prototypes should be avoided in .h files > #77: FILE: arch/powerpc/include/asm/udbg.h:56: > +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
Re: [PATCH] powerpc: Add support for early debugging via Serial 16550 console
On Monday 22 August 2022 14:13:30 Christophe Leroy wrote: > >> CONFIG_PPC_EARLY_DEBUG_16550=y > >> # CONFIG_PPC_EARLY_DEBUG_MEMCONS is not set > >> CONFIG_PPC_EARLY_DEBUG_16550_PHYSADDR= > >> CONFIG_PPC_EARLY_DEBUG_16550_STRIDE=1 > >> > >> which then causes a kconfig prompt when starting > >> the build... > > > > Cannot we set somehow that PPC_EARLY_DEBUG_16550 would be disabled by > > default when upgrading defconfig? > > The only solution I see is to put it at the end of the list, so that the > previous default value which is PPC_EARLY_DEBUG_MEMCONS gets selected. Does it work for all cases? If yes, then it looks like an elegant solution.
Re: [PATCH] powerpc: Add support for early debugging via Serial 16550 console
Le 19/08/2022 à 23:12, Pali Rohár a écrit : > 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 > --- > 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/ Build failure if I select it on mpc885_ads_defconfig : LD vmlinux.o MODPOST vmlinux.symvers MODINFO modules.builtin.modinfo GEN modules.builtin CC .vmlinux.export.o LD .tmp_vmlinux.kallsyms1 powerpc64-linux-ld: arch/powerpc/kernel/udbg.o: in function `udbg_early_init': /home/chleroy/linux-powerpc/arch/powerpc/kernel/udbg.c:71: undefined reference to `udbg_init_debug_16550' > --- > arch/powerpc/Kconfig.debug | 14 ++ > arch/powerpc/include/asm/udbg.h | 1 + > arch/powerpc/kernel/udbg.c | 2 ++ > arch/powerpc/kernel/udbg_16550.c | 33 > 4 files changed, 50 insertions(+) > > diff --git a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kconfig.debug > index 9f363c143d86..a4e7d90a45d2 100644 > --- a/arch/powerpc/Kconfig.debug > +++ b/arch/powerpc/Kconfig.debug > @@ -276,6 +276,11 @@ config PPC_EARLY_DEBUG_OPAL_HVSI > Select this to enable early debugging for the PowerNV platform > using an "hvsi" console > > +config PPC_EARLY_DEBUG_16550 > + bool "Serial 16550" > + help > + Select this to enable early debugging via Serial 16550 console > + Putting it before EARLY_DEBUG_MEMCONS means that configs that were previously selectiong EARLY_DEBUG_MEMCONS will now select EARLY_DEBUG_16550 instead. Add a dependency to PPC_UDBG_16550 to avoid the build failure I mentionned ? > config PPC_EARLY_DEBUG_MEMCONS > bool "In memory console" > help > @@ -355,6 +360,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 A default value is necessary here to avoid prompts during defconfig builds. > + > +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); 'extern' keywork is pointless and deprecated for function prototypes, please don't add new ones. Checkpatch reports: CHECK: extern prototypes should be avoided in .h files #77: FILE: arch/powerpc/include/asm/udbg.h:56: +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
Re: [PATCH] powerpc: Add support for early debugging via Serial 16550 console
Le 20/08/2022 à 00:43, Randy Dunlap a écrit : > > > On 8/19/22 15:38, Pali Rohár wrote: >> On Friday 19 August 2022 15:34:14 Randy Dunlap wrote: >>> Hi-- >>> >>> On 8/19/22 14:12, 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 --- 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 | 14 ++ arch/powerpc/include/asm/udbg.h | 1 + arch/powerpc/kernel/udbg.c | 2 ++ arch/powerpc/kernel/udbg_16550.c | 33 4 files changed, 50 insertions(+) diff --git a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kconfig.debug index 9f363c143d86..a4e7d90a45d2 100644 --- a/arch/powerpc/Kconfig.debug +++ b/arch/powerpc/Kconfig.debug @@ -276,6 +276,11 @@ config PPC_EARLY_DEBUG_OPAL_HVSI Select this to enable early debugging for the PowerNV platform using an "hvsi" console +config PPC_EARLY_DEBUG_16550 + bool "Serial 16550" + help +Select this to enable early debugging via Serial 16550 console + config PPC_EARLY_DEBUG_MEMCONS bool "In memory console" help @@ -355,6 +360,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 >>> >>> Is there any chance that you could provide a default value here >>> so that 'make olddefconfig' does not end up like it does >>> without having a default value? >> >> No. Because there is not any default value. Physical address of 16550 is >> hardly HW dependent. Possibly also bootloader dependent (if it can remap >> peripherals to different physical addresses). >> >> User _has to_ specify correct physical address if want to use early >> debug 16550 console. > > OK, we'll see if it ever causes a real problem then... It does, for instance with 83xx/mpc836x_rdk_defconfig > >>> CONFIG_PPC_EARLY_DEBUG_16550=y >>> # CONFIG_PPC_EARLY_DEBUG_MEMCONS is not set >>> CONFIG_PPC_EARLY_DEBUG_16550_PHYSADDR= >>> CONFIG_PPC_EARLY_DEBUG_16550_STRIDE=1 >>> >>> which then causes a kconfig prompt when starting >>> the build... >> >> Cannot we set somehow that PPC_EARLY_DEBUG_16550 would be disabled by >> default when upgrading defconfig? > > Don't know about that. > > Thanks.
Re: [PATCH] powerpc: Add support for early debugging via Serial 16550 console
Le 20/08/2022 à 00:38, Pali Rohár a écrit : > On Friday 19 August 2022 15:34:14 Randy Dunlap wrote: >> Hi-- >> >> On 8/19/22 14:12, 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 >>> --- >>> 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 | 14 ++ >>> arch/powerpc/include/asm/udbg.h | 1 + >>> arch/powerpc/kernel/udbg.c | 2 ++ >>> arch/powerpc/kernel/udbg_16550.c | 33 >>> 4 files changed, 50 insertions(+) >>> >>> diff --git a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kconfig.debug >>> index 9f363c143d86..a4e7d90a45d2 100644 >>> --- a/arch/powerpc/Kconfig.debug >>> +++ b/arch/powerpc/Kconfig.debug >>> @@ -276,6 +276,11 @@ config PPC_EARLY_DEBUG_OPAL_HVSI >>> Select this to enable early debugging for the PowerNV platform >>> using an "hvsi" console >>> >>> +config PPC_EARLY_DEBUG_16550 >>> + bool "Serial 16550" >>> + help >>> + Select this to enable early debugging via Serial 16550 console >>> + >>> config PPC_EARLY_DEBUG_MEMCONS >>> bool "In memory console" >>> help >>> @@ -355,6 +360,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 >> >> Is there any chance that you could provide a default value here >> so that 'make olddefconfig' does not end up like it does >> without having a default value? > > No. Because there is not any default value. Physical address of 16550 is > hardly HW dependent. Possibly also bootloader dependent (if it can remap > peripherals to different physical addresses). The exact same problem exists with EARLY_DEBUG_CPM. Nevertheless there is a default CONFIG_PPC_EARLY_DEBUG_CPM_ADDR. This value is wrong for some people, but at least it avoids prompt during the build of existing defconfig. Other solution is to update the defconfigs with the good value to avoid getting an empty value. > > User _has to_ specify correct physical address if want to use early > debug 16550 console. By the wait the build robot doesn't mind. > >> CONFIG_PPC_EARLY_DEBUG_16550=y >> # CONFIG_PPC_EARLY_DEBUG_MEMCONS is not set >> CONFIG_PPC_EARLY_DEBUG_16550_PHYSADDR= >> CONFIG_PPC_EARLY_DEBUG_16550_STRIDE=1 >> >> which then causes a kconfig prompt when starting >> the build... > > Cannot we set somehow that PPC_EARLY_DEBUG_16550 would be disabled by > default when upgrading defconfig? The only solution I see is to put it at the end of the list, so that the previous default value which is PPC_EARLY_DEBUG_MEMCONS gets selected. > >>> + >>> +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 >> >> Thanks. >> -- >> ~Randy
Re: [PATCH] powerpc: Add support for early debugging via Serial 16550 console
Le 20/08/2022 à 00:34, Randy Dunlap a écrit : > Hi-- > > On 8/19/22 14:12, 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 >> --- >> 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 | 14 ++ >> arch/powerpc/include/asm/udbg.h | 1 + >> arch/powerpc/kernel/udbg.c | 2 ++ >> arch/powerpc/kernel/udbg_16550.c | 33 >> 4 files changed, 50 insertions(+) >> >> diff --git a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kconfig.debug >> index 9f363c143d86..a4e7d90a45d2 100644 >> --- a/arch/powerpc/Kconfig.debug >> +++ b/arch/powerpc/Kconfig.debug >> @@ -276,6 +276,11 @@ config PPC_EARLY_DEBUG_OPAL_HVSI >>Select this to enable early debugging for the PowerNV platform >>using an "hvsi" console >> >> +config PPC_EARLY_DEBUG_16550 >> +bool "Serial 16550" >> +help >> + Select this to enable early debugging via Serial 16550 console >> + >> config PPC_EARLY_DEBUG_MEMCONS >> bool "In memory console" >> help >> @@ -355,6 +360,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 > > Is there any chance that you could provide a default value here > so that 'make olddefconfig' does not end up like it does > without having a default value? I did a few tests and it seems that a default doesn't help. I tried setting 'default n' to PPC_EARLY_DEBUG_16550 but I still get a prompt when doing an oldconfig. But only if you have CONFIG_PPC_EARLY_DEBUG=y in your old config. But that's expected behaviour when doing 'make oldconfig', isn't it ? Or are you meaning a defconfig ? Because I get what you describe when doing 83xx/mpc836x_rdk_defconfig. And I agree with you this is going to create problems. > > CONFIG_PPC_EARLY_DEBUG_16550=y > # CONFIG_PPC_EARLY_DEBUG_MEMCONS is not set > CONFIG_PPC_EARLY_DEBUG_16550_PHYSADDR= > CONFIG_PPC_EARLY_DEBUG_16550_STRIDE=1 > > which then causes a kconfig prompt when starting > the build... Maybe a solution is to make PPC_EARLY_DEBUG_MEMCONS the default, doing that I get no change from before. But that changes the behaviour for mpc885_ads_defconfig, so it is not the solution. So I think the only solution is to provide a default value to PPC_EARLY_DEBUG_16550_PHYSADDR, just like it is done for PPC_EARLY_DEBUG_CPM_ADDR. > >> + >> +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 > > Thanks.
Re: [PATCH net-next] Remove DECnet support from kernel
Hello: This patch was applied to netdev/net-next.git (master) by David S. Miller : On Wed, 17 Aug 2022 17:43:21 -0700 you wrote: > DECnet is an obsolete network protocol that receives more attention > from kernel janitors than users. It belongs in computer protocol > history museum not in Linux kernel. > > It has been "Orphaned" in kernel since 2010. The iproute2 support > for DECnet was dropped in 5.0 release. The documentation link on > Sourceforge says it is abandoned there as well. > > [...] Here is the summary with links: - [net-next] Remove DECnet support from kernel https://git.kernel.org/netdev/net-next/c/1202cdd66531 You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html
Re: [PATCH 1/3] dt-bindings: reset: syscon-reboot: Add priority property
On Monday 22 August 2022 07:47:28 Rob Herring wrote: > On Sat, Aug 20, 2022 at 12:29:23PM +0200, Pali Rohár wrote: > > This new optional priority property allows to specify custom priority level > > of reset device. Default level was always 192. > > Why do we need/want this? What problem does it solve? See patch 3/3. > > Signed-off-by: Pali Rohár > > --- > > .../devicetree/bindings/power/reset/syscon-reboot.yaml| 4 > > 1 file changed, 4 insertions(+) > > > > diff --git > > a/Documentation/devicetree/bindings/power/reset/syscon-reboot.yaml > > b/Documentation/devicetree/bindings/power/reset/syscon-reboot.yaml > > index da2509724812..d905133aab27 100644 > > --- a/Documentation/devicetree/bindings/power/reset/syscon-reboot.yaml > > +++ b/Documentation/devicetree/bindings/power/reset/syscon-reboot.yaml > > @@ -42,6 +42,10 @@ properties: > > $ref: /schemas/types.yaml#/definitions/uint32 > > description: The reset value written to the reboot register (32 bit > > access). > > > > + priority: > > A bit too generic for the name. > > > +$ref: /schemas/types.yaml#/definitions/sint32 > > +description: Priority level of this syscon reset device. Default 192. > > default: 192 > > > Though I'm not really sure about the whole concept of this in DT. Where > does 192 come from? Implicitly from the current implementation and how it is used. > Presumably if we have more than 1 reset device, then > 'priority' is needed in multiple places. So you need a common schema > defining the property (as property types should be defined exactly > once) which this schema can reference. > > Rob Sorry, I do not understand.
Re: [PATCH] powerpc: export cpu_smallcore_map for modules
On Mon, Aug 22, 2022 at 9:16 AM Christoph Hellwig wrote:
>
> On Mon, Aug 22, 2022 at 01:40:23PM +1000, Michael Ellerman wrote:
> > Randy Dunlap writes:
> > > drivers/gpu/drm/amd/amdkfd/kfd_device.c calls cpu_smt_mask().
> > > This is an inline function on powerpc which references
> > > cpu_smallcore_map.
> > >
> > > Fixes: 425752c63b6f ("powerpc: Detect the presence of big-cores via "ibm,
> > > thread-groups"")
> > > Fixes: 7bc913085765 ("drm/amdkfd: Try to schedule bottom half on same
> > > core")
> >
> > That 2nd commit is not in mainline, only linux-next.
> >
> > I don't mind merging this fix preemptively, but is that SHA stable?
>
> I really do not think this has any business being exported at all.
>
> kfd_queue_work is not something that should be done in a driver.
> Something like this belongs into the workqueue core, not in an
> underdocumented helper in a random driver.
>
> Drm guys: once again, please please work with the maintainers instead
> of just making up random stuff in the drivers.
Discussions are already ongoing with the workqueue folks. I'll drop
this for now.
Alex
Re: [PATCH 1/3] dt-bindings: reset: syscon-reboot: Add priority property
On Sat, Aug 20, 2022 at 12:29:23PM +0200, Pali Rohár wrote: > This new optional priority property allows to specify custom priority level > of reset device. Default level was always 192. Why do we need/want this? What problem does it solve? > Signed-off-by: Pali Rohár > --- > .../devicetree/bindings/power/reset/syscon-reboot.yaml| 4 > 1 file changed, 4 insertions(+) > > diff --git a/Documentation/devicetree/bindings/power/reset/syscon-reboot.yaml > b/Documentation/devicetree/bindings/power/reset/syscon-reboot.yaml > index da2509724812..d905133aab27 100644 > --- a/Documentation/devicetree/bindings/power/reset/syscon-reboot.yaml > +++ b/Documentation/devicetree/bindings/power/reset/syscon-reboot.yaml > @@ -42,6 +42,10 @@ properties: > $ref: /schemas/types.yaml#/definitions/uint32 > description: The reset value written to the reboot register (32 bit > access). > > + priority: A bit too generic for the name. > +$ref: /schemas/types.yaml#/definitions/sint32 > +description: Priority level of this syscon reset device. Default 192. default: 192 Though I'm not really sure about the whole concept of this in DT. Where does 192 come from? Presumably if we have more than 1 reset device, then 'priority' is needed in multiple places. So you need a common schema defining the property (as property types should be defined exactly once) which this schema can reference. Rob
Re: [PATCH] powerpc: export cpu_smallcore_map for modules
On Mon, Aug 22, 2022 at 01:40:23PM +1000, Michael Ellerman wrote:
> Randy Dunlap writes:
> > drivers/gpu/drm/amd/amdkfd/kfd_device.c calls cpu_smt_mask().
> > This is an inline function on powerpc which references
> > cpu_smallcore_map.
> >
> > Fixes: 425752c63b6f ("powerpc: Detect the presence of big-cores via "ibm,
> > thread-groups"")
> > Fixes: 7bc913085765 ("drm/amdkfd: Try to schedule bottom half on same core")
>
> That 2nd commit is not in mainline, only linux-next.
>
> I don't mind merging this fix preemptively, but is that SHA stable?
I really do not think this has any business being exported at all.
kfd_queue_work is not something that should be done in a driver.
Something like this belongs into the workqueue core, not in an
underdocumented helper in a random driver.
Drm guys: once again, please please work with the maintainers instead
of just making up random stuff in the drivers.
Re: [PATCH] i2c: pasemi: Add IRQ support for Apple Silicon
Hi Arminder,
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Arminder-Singh/i2c-pasemi-Add-IRQ-support-for-Apple-Silicon/20220821-034703
base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
config: parisc-randconfig-m031-20220821
(https://download.01.org/0day-ci/archive/20220822/202208220231.f88sizqa-...@intel.com/config)
compiler: hppa-linux-gcc (GCC) 12.1.0
If you fix the issue, kindly add following tag where applicable
Reported-by: kernel test robot
Reported-by: Dan Carpenter
smatch warnings:
drivers/i2c/busses/i2c-pasemi-core.c:92 pasemi_smb_waitready() error:
uninitialized symbol 'status'.
vim +/status +92 drivers/i2c/busses/i2c-pasemi-core.c
8032214346c0c8 drivers/i2c/busses/i2c-pasemi.c Julia Lawall 2010-09-05
80 static int pasemi_smb_waitready(struct pasemi_smbus *smbus)
beb58aa39e6e5a drivers/i2c/busses/i2c-pasemi.c Olof Johansson 2007-02-13
81 {
beb58aa39e6e5a drivers/i2c/busses/i2c-pasemi.c Olof Johansson 2007-02-13
82 int timeout = 10;
beb58aa39e6e5a drivers/i2c/busses/i2c-pasemi.c Olof Johansson 2007-02-13
83 unsigned int status;
98584b2b51d808 drivers/i2c/busses/i2c-pasemi-core.c Arminder Singh 2022-08-20
84 unsigned int bitmask = SMSTA_XEN | SMSTA_MTN;
beb58aa39e6e5a drivers/i2c/busses/i2c-pasemi.c Olof Johansson 2007-02-13
85
98584b2b51d808 drivers/i2c/busses/i2c-pasemi-core.c Arminder Singh 2022-08-20
86 if (smbus->use_irq) {
98584b2b51d808 drivers/i2c/busses/i2c-pasemi-core.c Arminder Singh 2022-08-20
87 reinit_completion(>irq_completion);
98584b2b51d808 drivers/i2c/busses/i2c-pasemi-core.c Arminder Singh 2022-08-20
88 reg_write(smbus, REG_IMASK, bitmask);
98584b2b51d808 drivers/i2c/busses/i2c-pasemi-core.c Arminder Singh 2022-08-20
89 wait_for_completion_timeout(>irq_completion,
msecs_to_jiffies(10));
beb58aa39e6e5a drivers/i2c/busses/i2c-pasemi.c Olof Johansson 2007-02-13
90 status = reg_read(smbus, REG_SMSTA);
98584b2b51d808 drivers/i2c/busses/i2c-pasemi-core.c Arminder Singh 2022-08-20
91 } else {
beb58aa39e6e5a drivers/i2c/busses/i2c-pasemi.c Olof Johansson 2007-02-13
@92 while (!(status & SMSTA_XEN) && timeout--) {
"status" not intialized.
beb58aa39e6e5a drivers/i2c/busses/i2c-pasemi.c Olof Johansson 2007-02-13
93 msleep(1);
beb58aa39e6e5a drivers/i2c/busses/i2c-pasemi.c Olof Johansson 2007-02-13
94 status = reg_read(smbus, REG_SMSTA);
beb58aa39e6e5a drivers/i2c/busses/i2c-pasemi.c Olof Johansson 2007-02-13
95 }
98584b2b51d808 drivers/i2c/busses/i2c-pasemi-core.c Arminder Singh 2022-08-20
96 }
98584b2b51d808 drivers/i2c/busses/i2c-pasemi-core.c Arminder Singh 2022-08-20
97
beb58aa39e6e5a drivers/i2c/busses/i2c-pasemi.c Olof Johansson 2007-02-13
98
be8a1f7cd4501c drivers/i2c/busses/i2c-pasemi.c Olof Johansson 2007-11-15
99 /* Got NACK? */
be8a1f7cd4501c drivers/i2c/busses/i2c-pasemi.c Olof Johansson 2007-11-15
100 if (status & SMSTA_MTN)
be8a1f7cd4501c drivers/i2c/busses/i2c-pasemi.c Olof Johansson 2007-11-15
101 return -ENXIO;
be8a1f7cd4501c drivers/i2c/busses/i2c-pasemi.c Olof Johansson 2007-11-15
102
beb58aa39e6e5a drivers/i2c/busses/i2c-pasemi.c Olof Johansson 2007-02-13
103 if (timeout < 0) {
c06f50ed36cc0a drivers/i2c/busses/i2c-pasemi.c Sven Peter 2021-10-08
104 dev_warn(smbus->dev, "Timeout, status 0x%08x\n", status);
beb58aa39e6e5a drivers/i2c/busses/i2c-pasemi.c Olof Johansson 2007-02-13
105 reg_write(smbus, REG_SMSTA, status);
beb58aa39e6e5a drivers/i2c/busses/i2c-pasemi.c Olof Johansson 2007-02-13
106 return -ETIME;
beb58aa39e6e5a drivers/i2c/busses/i2c-pasemi.c Olof Johansson 2007-02-13
107 }
beb58aa39e6e5a drivers/i2c/busses/i2c-pasemi.c Olof Johansson 2007-02-13
108
beb58aa39e6e5a drivers/i2c/busses/i2c-pasemi.c Olof Johansson 2007-02-13
109 /* Clear XEN */
beb58aa39e6e5a drivers/i2c/busses/i2c-pasemi.c Olof Johansson 2007-02-13
110 reg_write(smbus, REG_SMSTA, SMSTA_XEN);
beb58aa39e6e5a drivers/i2c/busses/i2c-pasemi.c Olof Johansson 2007-02-13
111
beb58aa39e6e5a drivers/i2c/busses/i2c-pasemi.c Olof Johansson 2007-02-13
112 return 0;
beb58aa39e6e5a drivers/i2c/busses/i2c-pasemi.c Olof Johansson 2007-02-13
113 }
--
0-DAY CI Kernel Test Service
https://01.org/lkp
Re: [6.0-rc1] Kernel crash while running MCE tests
On 8/22/22 11:01, Sachin Sant wrote: On 19-Aug-2022, at 10:12 AM, Ganesh wrote We'll have to make sure everything get_pseries_errorlog() is either forced inline, or marked noinstr. Making the following functions always_inline and noinstr is fixing the issue. __always_inline pseries_errorlog_id() __always_inline pseries_errorlog_length() __always_inline do_enter_rtas() __always_inline srr_regs_clobbered() noinstr va_rtas_call_unlocked() Shall I post the patch? Yes, thanks. I can help with testing. Sure, thanks.
Re: [6.0-rc1] Kernel crash while running MCE tests
On 8/22/22 11:19, Michael Ellerman wrote: So I guess the compiler has decided not to inline it (why?!), and it is not marked noinstr, so it gets KASAN instrumentation which crashes in real mode. We'll have to make sure everything get_pseries_errorlog() is either forced inline, or marked noinstr. Making the following functions always_inline and noinstr is fixing the issue. __always_inline pseries_errorlog_id() __always_inline pseries_errorlog_length() __always_inline do_enter_rtas() __always_inline srr_regs_clobbered() noinstr va_rtas_call_unlocked() Why do we need it? Because of fwnmi_release_errinfo()? Yes. Shall I post the patch? Yeah. cheers
Re: [PATCH linux-next] powerpc: disable sanitizer in irq_soft_mask_set
Le 21/08/2022 à 03:00, Zhouyi Zhou a écrit :
> In ppc, compiler based sanitizer will generate instrument instructions
> around statement WRITE_ONCE(local_paca->irq_soft_mask, mask):
>
> 0xc0295cb0 <+0>: addis r2,r12,774
> 0xc0295cb4 <+4>: addir2,r2,16464
> 0xc0295cb8 <+8>: mflrr0
> 0xc0295cbc <+12>: bl 0xc008bb4c
> 0xc0295cc0 <+16>: mflrr0
> 0xc0295cc4 <+20>: std r31,-8(r1)
> 0xc0295cc8 <+24>: addir3,r13,2354
> 0xc0295ccc <+28>: mr r31,r13
> 0xc0295cd0 <+32>: std r0,16(r1)
> 0xc0295cd4 <+36>: stdur1,-48(r1)
> 0xc0295cd8 <+40>: bl 0xc0609b98 <__asan_store1+8>
> 0xc0295cdc <+44>: nop
> 0xc0295ce0 <+48>: li r9,1
> 0xc0295ce4 <+52>: stb r9,2354(r31)
> 0xc0295ce8 <+56>: addir1,r1,48
> 0xc0295cec <+60>: ld r0,16(r1)
> 0xc0295cf0 <+64>: ld r31,-8(r1)
> 0xc0295cf4 <+68>: mtlrr0
>
> If there is a context switch before "stb r9,2354(r31)", r31 may
> not equal to r13, in such case, irq soft mask will not work.
>
> This patch disable sanitizer in irq_soft_mask_set.
Well spotted, thanks.
You should add:
Fixes: ef5b570d3700 ("powerpc/irq: Don't open code irq_soft_mask helpers")
By the way, I think the READ_ONCE() likely has the same issue so you
should fix irq_soft_mask_return() at the same time.
>
> Signed-off-by: Zhouyi Zhou
> ---
> Dear PPC developers
>
> I found this bug when trying to do rcutorture tests in ppc VM of
> Open Source Lab of Oregon State University following Paul E. McKenny's
> guidance.
>
> console.log report following bug:
>
> [ 346.527467][ T100] BUG: using smp_processor_id() in preemptible
> [] code: rcu_torture_rea/100^M
> [ 346.529416][ T100] caller is
> rcu_preempt_deferred_qs_irqrestore+0x74/0xed0^M
> [ 346.531157][ T100] CPU: 4 PID: 100 Comm: rcu_torture_rea Tainted: G
> W 5.19.0-rc5-next-20220708-dirty #253^M
> [ 346.533620][ T100] Call Trace:^M
> [ 346.534449][ T100] [c94876c0] [c0ce2b68]
> dump_stack_lvl+0xbc/0x108 (unreliable)^M
> [ 346.536632][ T100] [c9487710] [c1712954]
> check_preemption_disabled+0x154/0x160^M
> [ 346.538665][ T100] [c94877a0] [c02ce2d4]
> rcu_preempt_deferred_qs_irqrestore+0x74/0xed0^M
> [ 346.540830][ T100] [c94878b0] [c02cf3c0]
> __rcu_read_unlock+0x290/0x3b0^M
> [ 346.542746][ T100] [c9487910] [c02bb330]
> rcu_torture_read_unlock+0x30/0xb0^M
> [ 346.544779][ T100] [c9487930] [c02b7ff8]
> rcutorture_one_extend+0x198/0x810^M
> [ 346.546851][ T100] [c9487a10] [c02b8bfc]
> rcu_torture_one_read+0x58c/0xc90^M
> [ 346.548844][ T100] [c9487ca0] [c02b942c]
> rcu_torture_reader+0x12c/0x360^M
> [ 346.550784][ T100] [c9487db0] [c01de978]
> kthread+0x1e8/0x220^M
> [ 346.552555][ T100] [c9487e10] [c000cd54]
> ret_from_kernel_thread+0x5c/0x64^M
>
> After 12 days debugging, I finally narrow the problem to irq_soft_mask_set.
>
> I am a beginner, hope I can be of some beneficial to the community ;-)
>
> Thanks
> Zhouyi
> --
> arch/powerpc/include/asm/hw_irq.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/include/asm/hw_irq.h
> b/arch/powerpc/include/asm/hw_irq.h
> index 26ede09c521d..a5ae8d82cc9d 100644
> --- a/arch/powerpc/include/asm/hw_irq.h
> +++ b/arch/powerpc/include/asm/hw_irq.h
> @@ -121,7 +121,7 @@ static inline notrace unsigned long
> irq_soft_mask_return(void)
>* for the critical section and as a clobber because
>* we changed paca->irq_soft_mask
>*/
> -static inline notrace void irq_soft_mask_set(unsigned long mask)
> +static inline notrace __no_kcsan __no_sanitize_address void
> irq_soft_mask_set(unsigned long mask)
> {
> /*
>* The irq mask must always include the STD bit if any are set.
