[PATCH net v5] net: wan: Add checks for NULL for utdm in undo_uhdlc_init and unmap_si_regs
If uhdlc_priv_tsa != 1 then utdm is not initialized.
And if ret != NULL then goto undo_uhdlc_init, where
utdm is dereferenced. Same if dev == NULL.
Found by Astra Linux on behalf of Linux Verification Center
(linuxtesting.org) with SVACE.
Fixes: 8d68100ab4ad ("soc/fsl/qe: fix err handling of ucc_of_parse_tdm")
Signed-off-by: Esina Ekaterina
---
v5: Fix style
v4: Fix style
v3: Remove braces
v2: Add check for NULL for unmap_si_regs
---
drivers/net/wan/fsl_ucc_hdlc.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wan/fsl_ucc_hdlc.c b/drivers/net/wan/fsl_ucc_hdlc.c
index 22edea6ca4b8..1c53b5546927 100644
--- a/drivers/net/wan/fsl_ucc_hdlc.c
+++ b/drivers/net/wan/fsl_ucc_hdlc.c
@@ -1243,9 +1243,11 @@ static int ucc_hdlc_probe(struct platform_device *pdev)
free_dev:
free_netdev(dev);
undo_uhdlc_init:
- iounmap(utdm->siram);
+ if (utdm)
+ iounmap(utdm->siram);
unmap_si_regs:
- iounmap(utdm->si_regs);
+ if (utdm)
+ iounmap(utdm->si_regs);
free_utdm:
if (uhdlc_priv->tsa)
kfree(utdm);
--
2.39.0
[PATCH V2] PCI/AER: Configure ECRC only AER is native
As the ECRC configuration bits are part of AER registers, configure
ECRC only if AER is natively owned by the kernel.
Signed-off-by: Vidya Sagar
---
v2:
* Updated kernel-parameters.txt document based on Bjorn's suggestion
Documentation/admin-guide/kernel-parameters.txt | 4 +++-
drivers/pci/pcie/aer.c | 3 +++
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index 426fa892d311..8f85a1230525 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -4242,7 +4242,9 @@
specified, e.g., 12@pci:8086:9c22:103c:198f
for 4096-byte alignment.
ecrc= Enable/disable PCIe ECRC (transaction layer
- end-to-end CRC checking).
+ end-to-end CRC checking). Only effective if
+ OS has native AER control (either granted by
+ ACPI _OSC or forced via "pcie_ports=native")
bios: Use BIOS/firmware settings. This is the
the default.
off: Turn ECRC off
diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
index e2d8a74f83c3..730b47bdcdef 100644
--- a/drivers/pci/pcie/aer.c
+++ b/drivers/pci/pcie/aer.c
@@ -184,6 +184,9 @@ static int disable_ecrc_checking(struct pci_dev *dev)
*/
void pcie_set_ecrc_checking(struct pci_dev *dev)
{
+ if (!pcie_aer_is_native(dev))
+ return;
+
switch (ecrc_policy) {
case ECRC_POLICY_DEFAULT:
return;
--
2.17.1
Re: [PATCH V1] PCI/AER: Configure ECRC only AER is native
On 1/12/2023 10:36 AM, Sathyanarayanan Kuppuswamy wrote: External email: Use caution opening links or attachments On 1/11/23 8:59 PM, Vidya Sagar wrote: On 1/12/2023 9:18 AM, Sathyanarayanan Kuppuswamy wrote: External email: Use caution opening links or attachments On 1/11/23 7:33 PM, Vidya Sagar wrote: I think we still need bios option. For example, consider a system where BIOS needs to keep ECRC enabled for integrity reasons but if kernel doesn't want it for perf reasons, then, kernel can always use 'ecrc=off' option. I agree that "on" and "off" option makes sense. Since the kernel defaults ecrc setting to "bios", why again allow it as a command line option? Agree. "on" and "off" are fine but "default" is redundant. Do you want me to push a change to remove that as part of this patch itself? I think it is more like a cleanup and should go separately. IMO, the "bios" option cleanup and command line update from Bjorn can be in one patch, and your change could be a separate patch. But it is up to you and Bjorn. I think Bjorn's command line suggestion should go along with my patch otherwise the ECRC control through command line doesn't work if OS doesn't own the AER. So, it helps to make it explicit that the 'ecrc=' option works only if either kernel has native AER control or 'pcie_ports' is set to 'native' -- Sathyanarayanan Kuppuswamy Linux Kernel Developer -- Sathyanarayanan Kuppuswamy Linux Kernel Developer
Re: [PATCH v4] net: wan: Add checks for NULL for utdm in undo_uhdlc_init and unmap_si_regs
On Wed, Jan 11, 2023 at 10:55:33PM +0300, Esina Ekaterina wrote: > If uhdlc_priv_tsa != 1 then utdm is not initialized. > And if ret != NULL then goto undo_uhdlc_init, where > utdm is dereferenced. Same if dev == NULL. > > Found by Astra Linux on behalf of Linux Verification Center > (linuxtesting.org) with SVACE. > > Signed-off-by: Esina Ekaterina > --- > v4: Fix style > v3: Remove braces > v2: Add check for NULL for unmap_si_regs > --- > drivers/net/wan/fsl_ucc_hdlc.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) In addition to what Jakub said, please don't send patches as reply-to. Please sent them as new threads. Thanks
Re: [PATCH V1] PCI/AER: Configure ECRC only AER is native
On 1/11/23 8:59 PM, Vidya Sagar wrote: > > > On 1/12/2023 9:18 AM, Sathyanarayanan Kuppuswamy wrote: >> External email: Use caution opening links or attachments >> >> >> On 1/11/23 7:33 PM, Vidya Sagar wrote: >>> I think we still need bios option. For example, consider a system where >>> BIOS needs to keep ECRC enabled for integrity reasons but if kernel doesn't >>> want it for perf reasons, then, kernel can always use 'ecrc=off' option. >> >> I agree that "on" and "off" option makes sense. Since the kernel defaults >> ecrc setting to "bios", why again allow it as a command line option? > > Agree. "on" and "off" are fine but "default" is redundant. Do you want me to > push a change to remove that as part of this patch itself? I think > it is more like a cleanup and should go separately. IMO, the "bios" option cleanup and command line update from Bjorn can be in one patch, and your change could be a separate patch. But it is up to you and Bjorn. > >> >> -- >> Sathyanarayanan Kuppuswamy >> Linux Kernel Developer -- Sathyanarayanan Kuppuswamy Linux Kernel Developer
Re: [PATCH V1] PCI/AER: Configure ECRC only AER is native
On 1/12/2023 9:18 AM, Sathyanarayanan Kuppuswamy wrote: External email: Use caution opening links or attachments On 1/11/23 7:33 PM, Vidya Sagar wrote: I think we still need bios option. For example, consider a system where BIOS needs to keep ECRC enabled for integrity reasons but if kernel doesn't want it for perf reasons, then, kernel can always use 'ecrc=off' option. I agree that "on" and "off" option makes sense. Since the kernel defaults ecrc setting to "bios", why again allow it as a command line option? Agree. "on" and "off" are fine but "default" is redundant. Do you want me to push a change to remove that as part of this patch itself? I think it is more like a cleanup and should go separately. -- Sathyanarayanan Kuppuswamy Linux Kernel Developer
Re: [PATCH V1] PCI/AER: Configure ECRC only AER is native
On 1/11/23 7:33 PM, Vidya Sagar wrote: > I think we still need bios option. For example, consider a system where BIOS > needs to keep ECRC enabled for integrity reasons but if kernel doesn't want > it for perf reasons, then, kernel can always use 'ecrc=off' option. I agree that "on" and "off" option makes sense. Since the kernel defaults ecrc setting to "bios", why again allow it as a command line option? -- Sathyanarayanan Kuppuswamy Linux Kernel Developer
Re: [PATCH V1] PCI/AER: Configure ECRC only AER is native
On 1/12/2023 4:57 AM, Sathyanarayanan Kuppuswamy wrote:
External email: Use caution opening links or attachments
Hi,
On 1/11/23 3:10 PM, Bjorn Helgaas wrote:
On Wed, Jan 11, 2023 at 01:42:21PM -0800, Sathyanarayanan Kuppuswamy wrote:
On 1/11/23 12:31 PM, Vidya Sagar wrote:
As the ECRC configuration bits are part of AER registers, configure
ECRC only if AER is natively owned by the kernel.
ecrc command line option takes "bios/on/off" as possible options. It
does not clarify whether "on/off" choices can only be used if AER is
owned by OS or it can override the ownership of ECRC configuration
similar to pcie_ports=native option. Maybe that needs to be clarified.
Good point, what do you think of an update like this:
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index 6cfa6e3996cf..f7b40a439194 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -4296,7 +4296,9 @@
specified, e.g., 12@pci:8086:9c22:103c:198f
for 4096-byte alignment.
ecrc= Enable/disable PCIe ECRC (transaction layer
- end-to-end CRC checking).
+ end-to-end CRC checking). Only effective
+ if OS has native AER control (either granted by
+ ACPI _OSC or forced via "pcie_ports=native").
bios: Use BIOS/firmware settings. This is the
the default.
off: Turn ECRC off
I'm also fine with this change. I'll take it in V2.
Looks fine. But do we even need "bios" option? Since it is the default
value, I am not sure why we need to list that as an option again. IMO
this could be removed.
I think we still need bios option. For example, consider a system where
BIOS needs to keep ECRC enabled for integrity reasons but if kernel
doesn't want it for perf reasons, then, kernel can always use 'ecrc=off'
option.
I don't know whether the "ecrc=" parameter is really needed. If we
were adding it today, I would ask "why not enable ECRC wherever it is
supported?" If there are devices where it's broken, we could always
add quirks to disable it on a case-by-case basis.
Checking the original patch which added it, it looks like the intention
is to give option to boost performance over integrity.
commit 43c16408842b0eeb367c23a6fa540ce69f99e347
Author: Andrew Patterson
Date: Wed Apr 22 16:52:09 2009 -0600
PCI: Add support for turning PCIe ECRC on or off
Adds support for PCI Express transaction layer end-to-end CRC checking
(ECRC). This patch will enable/disable ECRC checking by setting/clearing
the ECRC Check Enable and/or ECRC Generation Enable bits for devices that
support ECRC.
The ECRC setting is controlled by the "pci=ecrc=" command-line
option. If this option is not set or is set to 'bios", the enable and
generation bits are left in whatever state that firmware/BIOS set them to.
The "off" setting turns them off, and the "on" option turns them on (if the
device supports it).
Turning ECRC on or off can be a data integrity versus performance
tradeoff. In theory, turning it on will catch more data errors, turning
it off means possibly better performance since CRC does not need to be
calculated by the PCIe hardware and packet sizes are reduced.
But I think the patch below is the right thing to do for now. Vidya,
Agree.
did you trip over an issue because of this, e.g., a conflict between
firmware use of AER and Linux use of it? If so, maybe we could
mention a symptom on the commit log. But my guess is you probably
found this by inspection.
Not really. I was just checking when does kernel touch ECRC settings and
happened to find this where it configures ECRC irrespective of its
ownership of AER registers.
Bjorn
Signed-off-by: Vidya Sagar
---
drivers/pci/pcie/aer.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
index e2d8a74f83c3..730b47bdcdef 100644
--- a/drivers/pci/pcie/aer.c
+++ b/drivers/pci/pcie/aer.c
@@ -184,6 +184,9 @@ static int disable_ecrc_checking(struct pci_dev *dev)
*/
void pcie_set_ecrc_checking(struct pci_dev *dev)
{
+ if (!pcie_aer_is_native(dev))
+ return;
+
switch (ecrc_policy) {
case ECRC_POLICY_DEFAULT:
return;
--
Sathyanarayanan Kuppuswamy
Linux Kernel Developer
--
Sathyanarayanan Kuppuswamy
Linux Kernel Developer
[PATCH v2 08/14] powerpc/vdso: Remove an unsupported flag from vgettimeofday-32.o with clang
When clang's -Qunused-arguments is dropped from KBUILD_CPPFLAGS, it warns: clang-16: error: argument unused during compilation: '-fno-stack-clash-protection' [-Werror,-Wunused-command-line-argument] This warning happens because vgettimeofday-32.c gets its base CFLAGS from the main kernel, which may contain flags that are only supported on a 64-bit target but not a 32-bit one, which is the case here. -fstack-clash-protection and its negation are only suppported by the 64-bit powerpc target but that flag is included in an invocation for a 32-bit powerpc target, so clang points out that while the flag is one that it recognizes, it is not actually used by this compiler job. To eliminate the warning, remove -fno-stack-clash-protection from vgettimeofday-32.c's CFLAGS when using clang, as has been done for other flags previously. Signed-off-by: Nathan Chancellor Reviewed-by: Nick Desaulniers --- Cc: m...@ellerman.id.au Cc: npig...@gmail.com Cc: christophe.le...@csgroup.eu Cc: linuxppc-dev@lists.ozlabs.org --- arch/powerpc/kernel/vdso/Makefile | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/powerpc/kernel/vdso/Makefile b/arch/powerpc/kernel/vdso/Makefile index 4337b3aa9171..e78a57e0a6c0 100644 --- a/arch/powerpc/kernel/vdso/Makefile +++ b/arch/powerpc/kernel/vdso/Makefile @@ -16,6 +16,11 @@ ifneq ($(c-gettimeofday-y),) CFLAGS_vgettimeofday-32.o += -ffreestanding -fasynchronous-unwind-tables CFLAGS_REMOVE_vgettimeofday-32.o = $(CC_FLAGS_FTRACE) CFLAGS_REMOVE_vgettimeofday-32.o += -mcmodel=medium -mabi=elfv1 -mabi=elfv2 -mcall-aixdesc + # This flag is supported by clang for 64-bit but not 32-bit so it will cause + # an unused command line flag warning for this file. + ifdef CONFIG_CC_IS_CLANG + CFLAGS_REMOVE_vgettimeofday-32.o += -fno-stack-clash-protection + endif CFLAGS_vgettimeofday-64.o += -include $(c-gettimeofday-y) CFLAGS_vgettimeofday-64.o += $(DISABLE_LATENT_ENTROPY_PLUGIN) CFLAGS_vgettimeofday-64.o += $(call cc-option, -fno-stack-protector) -- 2.39.0
[PATCH v2 05/14] powerpc: Remove linker flag from KBUILD_AFLAGS
When clang's -Qunused-arguments is dropped from KBUILD_CPPFLAGS, it
points out that KBUILD_AFLAGS contains a linker flag, which will be
used:
clang: error: -Wl,-a32: 'linker' input unused
[-Werror,-Wunused-command-line-argument]
This was likely supposed to be '-Wa,-a$(BITS)'. However, this change is
unnecessary, as all supported versions of clang and gcc will pass '-a64'
or '-a32' to GNU as based on the value of '-m'; the behavior of the
latest stable release of the oldest supported major version of each
compiler is shown below and each compiler's latest release exhibits the
same behavior (GCC 12.2.0 and Clang 15.0.6).
$ powerpc64-linux-gcc --version | head -1
powerpc64-linux-gcc (GCC) 5.5.0
$ powerpc64-linux-gcc -m64 -### -x assembler-with-cpp -c -o /dev/null
/dev/null &| grep 'as '
.../as -a64 -mppc64 -many -mbig -o /dev/null /tmp/cctwuBzZ.s
$ powerpc64-linux-gcc -m32 -### -x assembler-with-cpp -c -o /dev/null
/dev/null &| grep 'as '
.../as -a32 -mppc -many -mbig -o /dev/null /tmp/ccaZP4mF.sg
$ clang --version | head -1
Ubuntu clang version
11.1.0-++20211011094159+1fdec59bffc1-1~exp1~20211011214622.5
$ clang --target=powerpc64-linux-gnu -fno-integrated-as -m64 -### \
-x assembler-with-cpp -c -o /dev/null /dev/null &| grep gnu-as
"/usr/bin/powerpc64-linux-gnu-as" "-a64" "-mppc64" "-many" "-o" "/dev/null"
"/tmp/null-80267c.s"
$ clang --target=powerpc64-linux-gnu -fno-integrated-as -m64 -### \
-x assembler-with-cpp -c -o /dev/null /dev/null &| grep gnu-as
"/usr/bin/powerpc64-linux-gnu-as" "-a32" "-mppc" "-many" "-o" "/dev/null"
"/tmp/null-ab8f8d.s"
Remove this flag altogether to avoid future issues.
Fixes: 1421dc6d4829 ("powerpc/kbuild: Use flags variables rather than
overriding LD/CC/AS")
Signed-off-by: Nathan Chancellor
Reviewed-by: Nick Desaulniers
---
Cc: m...@ellerman.id.au
Cc: npig...@gmail.com
Cc: christophe.le...@csgroup.eu
Cc: linuxppc-dev@lists.ozlabs.org
---
arch/powerpc/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index dc4cbf0a5ca9..4fd630efe39d 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -90,7 +90,7 @@ aflags-$(CONFIG_CPU_LITTLE_ENDIAN)+= -mlittle-endian
ifeq ($(HAS_BIARCH),y)
KBUILD_CFLAGS += -m$(BITS)
-KBUILD_AFLAGS += -m$(BITS) -Wl,-a$(BITS)
+KBUILD_AFLAGS += -m$(BITS)
KBUILD_LDFLAGS += -m elf$(BITS)$(LDEMULATION)
endif
--
2.39.0
[PATCH v2 07/14] powerpc/vdso: Improve linker flags
When clang's -Qunused-arguments is dropped from KBUILD_CPPFLAGS, there
are several warnings in the PowerPC vDSO:
clang-16: error: -Wl,-soname=linux-vdso32.so.1: 'linker' input unused
[-Werror,-Wunused-command-line-argument]
clang-16: error: -Wl,--hash-style=both: 'linker' input unused
[-Werror,-Wunused-command-line-argument]
clang-16: error: argument unused during compilation: '-shared'
[-Werror,-Wunused-command-line-argument]
clang-16: error: argument unused during compilation: '-nostdinc'
[-Werror,-Wunused-command-line-argument]
clang-16: error: argument unused during compilation: '-Wa,-maltivec'
[-Werror,-Wunused-command-line-argument]
The first group of warnings point out that linker flags were being added
to all invocations of $(CC), even though they will only be used during
the final vDSO link. Move those flags to ldflags-y.
The second group of warnings are compiler or assembler flags that will
be unused during linking. Filter them out from KBUILD_CFLAGS so that
they are not used during linking.
Additionally, '-z noexecstack' was added directly to the ld_and_check
rule in commit 1d53c0192b15 ("powerpc/vdso: link with -z noexecstack")
but now that there is a common ldflags variable, it can be moved there.
Signed-off-by: Nathan Chancellor
Reviewed-by: Nick Desaulniers
---
Cc: m...@ellerman.id.au
Cc: npig...@gmail.com
Cc: christophe.le...@csgroup.eu
Cc: linuxppc-dev@lists.ozlabs.org
---
arch/powerpc/kernel/vdso/Makefile | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/kernel/vdso/Makefile
b/arch/powerpc/kernel/vdso/Makefile
index 45c0cc5d34b6..4337b3aa9171 100644
--- a/arch/powerpc/kernel/vdso/Makefile
+++ b/arch/powerpc/kernel/vdso/Makefile
@@ -47,13 +47,17 @@ KCOV_INSTRUMENT := n
UBSAN_SANITIZE := n
KASAN_SANITIZE := n
-ccflags-y := -shared -fno-common -fno-builtin -nostdlib -Wl,--hash-style=both
-ccflags-$(CONFIG_LD_IS_LLD) += $(call cc-option,--ld-path=$(LD),-fuse-ld=lld)
-
-CC32FLAGS := -Wl,-soname=linux-vdso32.so.1 -m32
+ccflags-y := -fno-common -fno-builtin
+ldflags-y := -Wl,--hash-style=both -nostdlib -shared -z noexecstack
+ldflags-$(CONFIG_LD_IS_LLD) += $(call cc-option,--ld-path=$(LD),-fuse-ld=lld)
+# Filter flags that clang will warn are unused for linking
+ldflags-y += $(filter-out $(CC_FLAGS_FTRACE) -Wa$(comma)%, $(KBUILD_CFLAGS))
+
+CC32FLAGS := -m32
+LD32FLAGS := -Wl,-soname=linux-vdso32.so.1
AS32FLAGS := -D__VDSO32__
-CC64FLAGS := -Wl,-soname=linux-vdso64.so.1
+LD64FLAGS := -Wl,-soname=linux-vdso64.so.1
AS64FLAGS := -D__VDSO64__
targets += vdso32.lds
@@ -92,14 +96,14 @@ include/generated/vdso64-offsets.h: $(obj)/vdso64.so.dbg
FORCE
# actual build commands
quiet_cmd_vdso32ld_and_check = VDSO32L $@
- cmd_vdso32ld_and_check = $(VDSOCC) $(c_flags) $(CC32FLAGS) -o $@
-Wl,-T$(filter %.lds,$^) $(filter %.o,$^) -z noexecstack ; $(cmd_vdso_check)
+ cmd_vdso32ld_and_check = $(VDSOCC) $(ldflags-y) $(CC32FLAGS)
$(LD32FLAGS) -o $@ -Wl,-T$(filter %.lds,$^) $(filter %.o,$^); $(cmd_vdso_check)
quiet_cmd_vdso32as = VDSO32A $@
cmd_vdso32as = $(VDSOCC) $(a_flags) $(CC32FLAGS) $(AS32FLAGS) -c -o $@ $<
quiet_cmd_vdso32cc = VDSO32C $@
cmd_vdso32cc = $(VDSOCC) $(c_flags) $(CC32FLAGS) -c -o $@ $<
quiet_cmd_vdso64ld_and_check = VDSO64L $@
- cmd_vdso64ld_and_check = $(VDSOCC) $(c_flags) $(CC64FLAGS) -o $@
-Wl,-T$(filter %.lds,$^) $(filter %.o,$^) -z noexecstack ; $(cmd_vdso_check)
+ cmd_vdso64ld_and_check = $(VDSOCC) $(ldflags-y) $(CC64FLAGS)
$(LD64FLAGS) -o $@ -Wl,-T$(filter %.lds,$^) $(filter %.o,$^); $(cmd_vdso_check)
quiet_cmd_vdso64as = VDSO64A $@
cmd_vdso64as = $(VDSOCC) $(a_flags) $(CC64FLAGS) $(AS64FLAGS) -c -o $@ $<
--
2.39.0
[PATCH v2 06/14] powerpc/vdso: Remove unused '-s' flag from ASFLAGS
When clang's -Qunused-arguments is dropped from KBUILD_CPPFLAGS, it warns: clang-16: error: argument unused during compilation: '-s' [-Werror,-Wunused-command-line-argument] The compiler's '-s' flag is a linking option (it is passed along to the linker directly), which means it does nothing when the linker is not invoked by the compiler. The kernel builds all .o files with '-c', which stops the compilation pipeline before linking, so '-s' can be safely dropped from ASFLAGS. Signed-off-by: Nathan Chancellor Reviewed-by: Nick Desaulniers Reviewed-by: Segher Boessenkool --- Cc: m...@ellerman.id.au Cc: npig...@gmail.com Cc: christophe.le...@csgroup.eu Cc: linuxppc-dev@lists.ozlabs.org As I mentioned before, it is possible that we should add '-s' to ldflags-y in the following patch but I assume someone would have noticed by now if that was a problem. --- arch/powerpc/kernel/vdso/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/kernel/vdso/Makefile b/arch/powerpc/kernel/vdso/Makefile index 6a977b0d8ffc..45c0cc5d34b6 100644 --- a/arch/powerpc/kernel/vdso/Makefile +++ b/arch/powerpc/kernel/vdso/Makefile @@ -51,10 +51,10 @@ ccflags-y := -shared -fno-common -fno-builtin -nostdlib -Wl,--hash-style=both ccflags-$(CONFIG_LD_IS_LLD) += $(call cc-option,--ld-path=$(LD),-fuse-ld=lld) CC32FLAGS := -Wl,-soname=linux-vdso32.so.1 -m32 -AS32FLAGS := -D__VDSO32__ -s +AS32FLAGS := -D__VDSO32__ CC64FLAGS := -Wl,-soname=linux-vdso64.so.1 -AS64FLAGS := -D__VDSO64__ -s +AS64FLAGS := -D__VDSO64__ targets += vdso32.lds CPPFLAGS_vdso32.lds += -P -C -Upowerpc -- 2.39.0
[PATCH v2 00/14] Remove clang's -Qunused-arguments from KBUILD_CPPFLAGS
Hi all,
Clang can emit a few different warnings when it encounters a flag that it
recognizes but does not support internally. These warnings are elevated to
errors within {as,cc}-option via -Werror to catch unsupported flags that should
not be added to KBUILD_{A,C}FLAGS; see commit c3f0d0bc5b01 ("kbuild, LLVMLinux:
Add -Werror to cc-option to support clang").
If an unsupported flag is unconditionally to KBUILD_{A,C}FLAGS, all subsequent
{as,cc}-option will always fail, preventing supported and even potentially
necessary flags from getting adding to the tool flags.
One would expect these warnings to be visible in the kernel build logs since
they are added to KBUILD_{A,C}FLAGS but unfortunately, these warnings are
hidden with clang's -Qunused-arguments flag, which is added to KBUILD_CPPFLAGS
and used for both compiling and assembling files.
Patches 1-4 address the internal inconsistencies of invoking the assembler
within kbuild by using KBUILD_AFLAGS consistently and using '-x
assembler-with-cpp' over '-x assembler'. This matches how assembly files are
built across the kernel and helps avoid problems in situations where macro
definitions or warning flags are present in KBUILD_AFLAGS, which cause
instances of -Wunused-command-line-argument when the preprocessor is not called
to consume them. There were a couple of places in architecture code where this
change would break things so those are fixed first.
Patches 5-12 clean up warnings that will show up when -Qunused-argument is
dropped. I hope none of these are controversial.
Patch 13 turns two warnings into errors so that the presence of unused flags
cannot be easily ignored.
Patch 14 drops -Qunused-argument. This is done last so that it can be easily
reverted if need be.
This series has seen my personal test framework, which tests several different
configurations and architectures, with LLVM tip of tree (16.0.0). I have done
defconfig, allmodconfig, and allnoconfig builds for arm, arm64, i386, mips,
powerpc, riscv, s390, and x86_64 with GCC 12.2.0 as well but I am hoping the
rest of the test infrastructure will catch any lurking problems.
I would like this series to stay together so that there is no opportunity for
breakage so please consider giving acks so that this can be carried via the
kbuild tree (and many thanks to the people who have already provided such
tags).
---
Changes in v2:
- Pick up tags where provided (thank you everyone!)
- Patch 6 and 9: Clarify that '-s' is a compiler flag that is only relevant to
the linking phase and remove all mention of the assembler's '-s' flag, as the
assembler is never directly invoked (Nick, Segher)
- Patch 7: Move '-z noexecstack' into new ldflags-y variable (Nick)
- Patch 8: Reword commit message to explain the problem in a clearer manner
(Nick)
- Link to v1:
https://lore.kernel.org/r/20221228-drop-qunused-arguments-v1-0-658cbc8fc...@kernel.org
---
Nathan Chancellor (12):
MIPS: Always use -Wa,-msoft-float and eliminate GAS_HAS_SET_HARDFLOAT
MIPS: Prefer cc-option for additions to cflags
powerpc: Remove linker flag from KBUILD_AFLAGS
powerpc/vdso: Remove unused '-s' flag from ASFLAGS
powerpc/vdso: Improve linker flags
powerpc/vdso: Remove an unsupported flag from vgettimeofday-32.o with
clang
s390/vdso: Drop unused '-s' flag from KBUILD_AFLAGS_64
s390/vdso: Drop '-shared' from KBUILD_CFLAGS_64
s390/purgatory: Remove unused '-MD' and unnecessary '-c' flags
drm/amd/display: Do not add '-mhard-float' to dml_ccflags for clang
kbuild: Turn a couple more of clang's unused option warnings into errors
kbuild: Stop using '-Qunused-arguments' with clang
Nick Desaulniers (2):
x86/boot/compressed: prefer cc-option for CFLAGS additions
kbuild: Update assembler calls to use proper flags and language target
Makefile| 1 -
arch/mips/Makefile | 13 ++---
arch/mips/include/asm/asmmacro-32.h | 4 +--
arch/mips/include/asm/asmmacro.h| 42 ++---
arch/mips/include/asm/fpregdef.h| 14 --
arch/mips/include/asm/mipsregs.h| 20 +++---
arch/mips/kernel/genex.S| 2 +-
arch/mips/kernel/r2300_fpu.S| 4 +--
arch/mips/kernel/r4k_fpu.S | 12 -
arch/mips/kvm/fpu.S | 6 ++---
arch/mips/loongson2ef/Platform | 2 +-
arch/powerpc/Makefile | 2 +-
arch/powerpc/kernel/vdso/Makefile | 25 +++--
arch/s390/kernel/vdso64/Makefile| 4 +--
arch/s390/purgatory/Makefile| 2 +-
arch/x86/boot/compressed/Makefile | 2 +-
drivers/gpu/drm/amd/display/dc/dml/Makefile | 3 ++-
scripts/Kconfig.include | 2 +-
scripts/Makefile.clang | 2 ++
scripts/Makefile.compiler | 8
Re: [PATCH] powerpc/secvar: Use u64 in secvar_operations
On Thu, 2023-01-12 at 13:38 +1100, Michael Ellerman wrote: > There's no reason for secvar_operations to use uint64_t vs the more > common kernel type u64. > > The types are compatible, but they require different printk format > strings which can lead to confusion. > > Change all the secvar related routines to use u64. > > Signed-off-by: Michael Ellerman Reviewed-by: Andrew Donnellan -- Andrew DonnellanOzLabs, ADL Canberra a...@linux.ibm.com IBM Australia Limited
Re: [PATCH] powerpc/secvar: Use u64 in secvar_operations
On Thu, 2023-01-12 at 13:38 +1100, Michael Ellerman wrote: > There's no reason for secvar_operations to use uint64_t vs the more > common kernel type u64. > > The types are compatible, but they require different printk format > strings which can lead to confusion. > > Change all the secvar related routines to use u64. > > Signed-off-by: Michael Ellerman Reviewed-by: Russell Currey
[PATCH] powerpc/secvar: Use u64 in secvar_operations
There's no reason for secvar_operations to use uint64_t vs the more
common kernel type u64.
The types are compatible, but they require different printk format
strings which can lead to confusion.
Change all the secvar related routines to use u64.
Signed-off-by: Michael Ellerman
---
arch/powerpc/include/asm/secvar.h| 9 +++--
arch/powerpc/kernel/secvar-sysfs.c | 8
arch/powerpc/platforms/powernv/opal-secvar.c | 9 +++--
security/integrity/platform_certs/load_powerpc.c | 4 ++--
4 files changed, 12 insertions(+), 18 deletions(-)
diff --git a/arch/powerpc/include/asm/secvar.h
b/arch/powerpc/include/asm/secvar.h
index 4cc35b58b986..07ba36f868a7 100644
--- a/arch/powerpc/include/asm/secvar.h
+++ b/arch/powerpc/include/asm/secvar.h
@@ -14,12 +14,9 @@
extern const struct secvar_operations *secvar_ops;
struct secvar_operations {
- int (*get)(const char *key, uint64_t key_len, u8 *data,
- uint64_t *data_size);
- int (*get_next)(const char *key, uint64_t *key_len,
- uint64_t keybufsize);
- int (*set)(const char *key, uint64_t key_len, u8 *data,
- uint64_t data_size);
+ int (*get)(const char *key, u64 key_len, u8 *data, u64 *data_size);
+ int (*get_next)(const char *key, u64 *key_len, u64 keybufsize);
+ int (*set)(const char *key, u64 key_len, u8 *data, u64 data_size);
};
#ifdef CONFIG_PPC_SECURE_BOOT
diff --git a/arch/powerpc/kernel/secvar-sysfs.c
b/arch/powerpc/kernel/secvar-sysfs.c
index 1ee4640a2641..001cdbcdb9d2 100644
--- a/arch/powerpc/kernel/secvar-sysfs.c
+++ b/arch/powerpc/kernel/secvar-sysfs.c
@@ -47,7 +47,7 @@ static ssize_t format_show(struct kobject *kobj, struct
kobj_attribute *attr,
static ssize_t size_show(struct kobject *kobj, struct kobj_attribute *attr,
char *buf)
{
- uint64_t dsize;
+ u64 dsize;
int rc;
rc = secvar_ops->get(kobj->name, strlen(kobj->name) + 1, NULL, );
@@ -64,8 +64,8 @@ static ssize_t data_read(struct file *filep, struct kobject
*kobj,
struct bin_attribute *attr, char *buf, loff_t off,
size_t count)
{
- uint64_t dsize;
char *data;
+ u64 dsize;
int rc;
rc = secvar_ops->get(kobj->name, strlen(kobj->name) + 1, NULL, );
@@ -166,9 +166,9 @@ static int update_kobj_size(void)
static int secvar_sysfs_load(void)
{
- char *name;
- uint64_t namesize = 0;
struct kobject *kobj;
+ u64 namesize = 0;
+ char *name;
int rc;
name = kzalloc(NAME_MAX_SIZE, GFP_KERNEL);
diff --git a/arch/powerpc/platforms/powernv/opal-secvar.c
b/arch/powerpc/platforms/powernv/opal-secvar.c
index 14133e120bdd..ef89861569e0 100644
--- a/arch/powerpc/platforms/powernv/opal-secvar.c
+++ b/arch/powerpc/platforms/powernv/opal-secvar.c
@@ -54,8 +54,7 @@ static int opal_status_to_err(int rc)
return err;
}
-static int opal_get_variable(const char *key, uint64_t ksize,
-u8 *data, uint64_t *dsize)
+static int opal_get_variable(const char *key, u64 ksize, u8 *data, u64 *dsize)
{
int rc;
@@ -71,8 +70,7 @@ static int opal_get_variable(const char *key, uint64_t ksize,
return opal_status_to_err(rc);
}
-static int opal_get_next_variable(const char *key, uint64_t *keylen,
- uint64_t keybufsize)
+static int opal_get_next_variable(const char *key, u64 *keylen, u64 keybufsize)
{
int rc;
@@ -88,8 +86,7 @@ static int opal_get_next_variable(const char *key, uint64_t
*keylen,
return opal_status_to_err(rc);
}
-static int opal_set_variable(const char *key, uint64_t ksize, u8 *data,
-uint64_t dsize)
+static int opal_set_variable(const char *key, u64 ksize, u8 *data, u64 dsize)
{
int rc;
diff --git a/security/integrity/platform_certs/load_powerpc.c
b/security/integrity/platform_certs/load_powerpc.c
index a2900cb85357..1e4f80a4e71c 100644
--- a/security/integrity/platform_certs/load_powerpc.c
+++ b/security/integrity/platform_certs/load_powerpc.c
@@ -18,7 +18,7 @@
/*
* Get a certificate list blob from the named secure variable.
*/
-static __init void *get_cert_list(u8 *key, unsigned long keylen, uint64_t
*size)
+static __init void *get_cert_list(u8 *key, unsigned long keylen, u64 *size)
{
int rc;
void *db;
@@ -51,7 +51,7 @@ static __init void *get_cert_list(u8 *key, unsigned long
keylen, uint64_t *size)
static int __init load_powerpc_certs(void)
{
void *db = NULL, *dbx = NULL;
- uint64_t dbsize = 0, dbxsize = 0;
+ u64 dbsize = 0, dbxsize = 0;
int rc = 0;
struct device_node *node;
--
2.39.0
[powerpc:fixes] BUILD SUCCESS 76d588dddc459fefa1da96e0a081a397c5c8e216
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git fixes branch HEAD: 76d588dddc459fefa1da96e0a081a397c5c8e216 powerpc/imc-pmu: Fix use of mutex in IRQs disabled section elapsed time: 724m configs tested: 94 configs skipped: 100 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: x86_64allnoconfig i386 allyesconfig i386defconfig arm64allyesconfig arm defconfig arm allyesconfig m68k allyesconfig m68k allmodconfig arc allyesconfig alphaallyesconfig x86_64 rhel-8.3-kvm x86_64 rhel-8.3-syz x86_64 rhel-8.3-bpf x86_64 rhel-8.3-kunit um x86_64_defconfig um i386_defconfig s390 zfcpdump_defconfig arm lubbock_defconfig powerpc redwood_defconfig sh rsk7203_defconfig shhp6xx_defconfig riscvrandconfig-r042-20230110 s390 randconfig-r044-20230110 arc randconfig-r043-20230110 ia64 allmodconfig x86_64 defconfig x86_64 allyesconfig x86_64 rhel-8.3 s390defconfig s390 allmodconfig arc defconfig alpha defconfig s390 allyesconfig powerpc allnoconfig mips allyesconfig powerpc allmodconfig sh allmodconfig x86_64randconfig-a011 x86_64randconfig-a013 x86_64randconfig-a015 x86_64 rhel-8.3-func x86_64rhel-8.3-kselftests mips decstation_defconfig mips ci20_defconfig powerpc pcm030_defconfig i386 randconfig-a012 i386 randconfig-a014 i386 randconfig-a016 x86_64randconfig-a006 x86_64randconfig-a004 x86_64randconfig-a002 arm gemini_defconfig powerpc tqm8548_defconfig i386 randconfig-a003 i386 randconfig-a001 i386 randconfig-a005 microblaze mmu_defconfig arm tegra_defconfig loongarch loongson3_defconfig parisc allyesconfig powerpc pasemi_defconfig mips bmips_be_defconfig xtensa virt_defconfig arcnsim_700_defconfig nios2 defconfig mips rt305x_defconfig arcvdk_hs38_defconfig sh sh7770_generic_defconfig loongarch defconfig m68k amcore_defconfig armmulti_v7_defconfig sh ul2_defconfig m68k alldefconfig powerpc mpc85xx_cds_defconfig powerpcklondike_defconfig nios2allyesconfig parisc defconfig parisc64defconfig clang tested configs: i386 randconfig-a002 i386 randconfig-a006 i386 randconfig-a004 x86_64randconfig-a005 x86_64randconfig-a003 x86_64randconfig-a001 x86_64randconfig-a014 x86_64randconfig-a016 x86_64randconfig-a012 x86_64 rhel-8.3-rust powerpc chrp32_defconfig powerpcfsp2_defconfig arm shannon_defconfig arm randconfig-r046-20230110 hexagon randconfig-r041-20230110 hexagon randconfig-r045-20230110 -- 0-DAY CI Kernel Test Service https://01.org/lkp
Re: [PATCH rcu 04/27] arch/powerpc/kvm: Remove "select SRCU"
On Thu, Jan 12, 2023 at 10:49:04AM +1100, Michael Ellerman wrote: > "Paul E. McKenney" writes: > > Now that the SRCU Kconfig option is unconditionally selected, there is > > no longer any point in selecting it. Therefore, remove the "select SRCU" > > Kconfig statements. > > > > Signed-off-by: Paul E. McKenney > > Cc: Michael Ellerman > > Cc: Nicholas Piggin > > Cc: Christophe Leroy > > Cc: > > --- > > arch/powerpc/kvm/Kconfig | 1 - > > 1 file changed, 1 deletion(-) > > Acked-by: Michael Ellerman (powerpc) Thank you! I will apply on the next rebase. Thanx, Paul > cheers > > > diff --git a/arch/powerpc/kvm/Kconfig b/arch/powerpc/kvm/Kconfig > > index a9f57dad6d916..902611954200d 100644 > > --- a/arch/powerpc/kvm/Kconfig > > +++ b/arch/powerpc/kvm/Kconfig > > @@ -22,7 +22,6 @@ config KVM > > select PREEMPT_NOTIFIERS > > select HAVE_KVM_EVENTFD > > select HAVE_KVM_VCPU_ASYNC_IOCTL > > - select SRCU > > select KVM_VFIO > > select IRQ_BYPASS_MANAGER > > select HAVE_KVM_IRQ_BYPASS > > -- > > 2.31.1.189.g2e36527f23
Re: [PATCH rcu 04/27] arch/powerpc/kvm: Remove "select SRCU"
"Paul E. McKenney" writes: > Now that the SRCU Kconfig option is unconditionally selected, there is > no longer any point in selecting it. Therefore, remove the "select SRCU" > Kconfig statements. > > Signed-off-by: Paul E. McKenney > Cc: Michael Ellerman > Cc: Nicholas Piggin > Cc: Christophe Leroy > Cc: > --- > arch/powerpc/kvm/Kconfig | 1 - > 1 file changed, 1 deletion(-) Acked-by: Michael Ellerman (powerpc) cheers > diff --git a/arch/powerpc/kvm/Kconfig b/arch/powerpc/kvm/Kconfig > index a9f57dad6d916..902611954200d 100644 > --- a/arch/powerpc/kvm/Kconfig > +++ b/arch/powerpc/kvm/Kconfig > @@ -22,7 +22,6 @@ config KVM > select PREEMPT_NOTIFIERS > select HAVE_KVM_EVENTFD > select HAVE_KVM_VCPU_ASYNC_IOCTL > - select SRCU > select KVM_VFIO > select IRQ_BYPASS_MANAGER > select HAVE_KVM_IRQ_BYPASS > -- > 2.31.1.189.g2e36527f23
Re: [PATCH V1] PCI/AER: Configure ECRC only AER is native
Hi,
On 1/11/23 3:10 PM, Bjorn Helgaas wrote:
> On Wed, Jan 11, 2023 at 01:42:21PM -0800, Sathyanarayanan Kuppuswamy wrote:
>> On 1/11/23 12:31 PM, Vidya Sagar wrote:
>>> As the ECRC configuration bits are part of AER registers, configure
>>> ECRC only if AER is natively owned by the kernel.
>>
>> ecrc command line option takes "bios/on/off" as possible options. It
>> does not clarify whether "on/off" choices can only be used if AER is
>> owned by OS or it can override the ownership of ECRC configuration
>> similar to pcie_ports=native option. Maybe that needs to be clarified.
>
> Good point, what do you think of an update like this:
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt
> b/Documentation/admin-guide/kernel-parameters.txt
> index 6cfa6e3996cf..f7b40a439194 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -4296,7 +4296,9 @@
> specified, e.g., 12@pci:8086:9c22:103c:198f
> for 4096-byte alignment.
> ecrc= Enable/disable PCIe ECRC (transaction layer
> - end-to-end CRC checking).
> + end-to-end CRC checking). Only effective
> + if OS has native AER control (either granted by
> + ACPI _OSC or forced via "pcie_ports=native").
> bios: Use BIOS/firmware settings. This is the
> the default.
> off: Turn ECRC off
Looks fine. But do we even need "bios" option? Since it is the default
value, I am not sure why we need to list that as an option again. IMO
this could be removed.
>
> I don't know whether the "ecrc=" parameter is really needed. If we
> were adding it today, I would ask "why not enable ECRC wherever it is
> supported?" If there are devices where it's broken, we could always
> add quirks to disable it on a case-by-case basis.
Checking the original patch which added it, it looks like the intention
is to give option to boost performance over integrity.
commit 43c16408842b0eeb367c23a6fa540ce69f99e347
Author: Andrew Patterson
Date: Wed Apr 22 16:52:09 2009 -0600
PCI: Add support for turning PCIe ECRC on or off
Adds support for PCI Express transaction layer end-to-end CRC checking
(ECRC). This patch will enable/disable ECRC checking by setting/clearing
the ECRC Check Enable and/or ECRC Generation Enable bits for devices that
support ECRC.
The ECRC setting is controlled by the "pci=ecrc=" command-line
option. If this option is not set or is set to 'bios", the enable and
generation bits are left in whatever state that firmware/BIOS set them to.
The "off" setting turns them off, and the "on" option turns them on (if the
device supports it).
Turning ECRC on or off can be a data integrity versus performance
tradeoff. In theory, turning it on will catch more data errors, turning
it off means possibly better performance since CRC does not need to be
calculated by the PCIe hardware and packet sizes are reduced.
>
> But I think the patch below is the right thing to do for now. Vidya,
Agree.
> did you trip over an issue because of this, e.g., a conflict between
> firmware use of AER and Linux use of it? If so, maybe we could
> mention a symptom on the commit log. But my guess is you probably
> found this by inspection.
>
> Bjorn
>
>>> Signed-off-by: Vidya Sagar
>>> ---
>>> drivers/pci/pcie/aer.c | 3 +++
>>> 1 file changed, 3 insertions(+)
>>>
>>> diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
>>> index e2d8a74f83c3..730b47bdcdef 100644
>>> --- a/drivers/pci/pcie/aer.c
>>> +++ b/drivers/pci/pcie/aer.c
>>> @@ -184,6 +184,9 @@ static int disable_ecrc_checking(struct pci_dev *dev)
>>> */
>>> void pcie_set_ecrc_checking(struct pci_dev *dev)
>>> {
>>> + if (!pcie_aer_is_native(dev))
>>> + return;
>>> +
>>> switch (ecrc_policy) {
>>> case ECRC_POLICY_DEFAULT:
>>> return;
>>
>> --
>> Sathyanarayanan Kuppuswamy
>> Linux Kernel Developer
--
Sathyanarayanan Kuppuswamy
Linux Kernel Developer
RE: usb.c:undefined reference to `qe_immr'
> -Original Message- > From: Christophe Leroy > Sent: Wednesday, January 11, 2023 1:43 PM > To: Randy Dunlap ; Michael Ellerman > ; kernel test robot ; Masahiro > Yamada > Cc: Nicolas Schier ; linux-ker...@vger.kernel.org; Leo Li > ; oe-kbuild-...@lists.linux.dev; linuxppc-dev > ; Qiang Zhao > Subject: Re: usb.c:undefined reference to `qe_immr' > > > > Le 11/01/2023 à 17:01, Randy Dunlap a écrit : > > > > > > On 1/10/23 23:39, Michael Ellerman wrote: > >> Randy Dunlap writes: > >>> [adding Cc's] > >>> > >>> > >>> On 1/9/23 23:59, kernel test robot wrote: > Hi Masahiro, > > FYI, the error/warning still remains. > > tree: > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.ke > rnel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git > ata=05%7C01%7Cleoyang.li%40nxp.com%7Cd7f37490b9ad42174b0408daf40c > 0376%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63809062972159 > 7124%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu > MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=uv8%2 > BzM6uKMc9VPSXwH60Hi4V27pIKvv7BPzAFA3GOK8%3D=0 master > head: 5a41237ad1d4b62008f93163af1d9b1da90729d8 > commit: 7b4537199a4a8480b8c3ba37a2d44765ce76cd9b kbuild: link > symbol CRCs at final link, removing CONFIG_MODULE_REL_CRCS > date: 8 months ago > config: powerpc-randconfig-r026-20230110 > compiler: powerpc-linux-gcc (GCC) 12.1.0 reproduce (this is a W=1 > build): > wget > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fraw.g > ithubusercontent.com%2Fintel%2Flkp- > tests%2Fmaster%2Fsbin%2Fmake.cross=05%7C01%7Cleoyang.li%40nx > p.com%7Cd7f37490b9ad42174b0408daf40c0376%7C686ea1d3bc2b4c6fa92cd9 > 9c5c301635%7C0%7C0%7C638090629721753373%7CUnknown%7CTWFpbGZs > b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn > 0%3D%7C3000%7C%7C%7C=bZocY77aLRAMjD3F1ttgzm%2F2tW8JfhYf > xq%2B6vxJh9Mc%3D=0 -O ~/bin/make.cross > chmod +x ~/bin/make.cross > # > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.ke > rnel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git%2 > Fcommit%2F%3Fid%3D7b4537199a4a8480b8c3ba37a2d44765ce76cd9b= > 05%7C01%7Cleoyang.li%40nxp.com%7Cd7f37490b9ad42174b0408daf40c0376 > %7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638090629721753373 > %7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL > CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=%2F%2BX1fl > KB1kjgv3wNK18Cu9uq6%2FUOr%2FCTjIsudBfiGho%3D=0 > git remote add linus > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.ke > rnel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git > ata=05%7C01%7Cleoyang.li%40nxp.com%7Cd7f37490b9ad42174b0408daf40c > 0376%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63809062972175 > 3373%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu > MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=%2BvI > %2BGkvbol1aWLlg%2FAF12%2F44xZeN8U1c%2B0Y%2BvGCadt0%3D > d=0 > git fetch --no-tags linus master > git checkout 7b4537199a4a8480b8c3ba37a2d44765ce76cd9b > # save the config file > mkdir build_dir && cp config build_dir/.config > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 > make.cross W=1 O=build_dir ARCH=powerpc olddefconfig > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 > make.cross W=1 O=build_dir ARCH=powerpc SHELL=/bin/bash > > If you fix the issue, kindly add following tag where applicable > | Reported-by: kernel test robot > > All errors (new ones prefixed by >>): > > powerpc-linux-ld: powerpc-linux-ld: DWARF error: could not find > abbrev number 74 > drivers/soc/fsl/qe/usb.o: in function `qe_usb_clock_set': > >> usb.c:(.text+0x1e): undefined reference to `qe_immr' > >> powerpc-linux-ld: usb.c:(.text+0x2a): undefined reference to > `qe_immr' > >> powerpc-linux-ld: usb.c:(.text+0xbc): undefined reference to > `qe_setbrg' > >> powerpc-linux-ld: usb.c:(.text+0xca): undefined reference to > `cmxgcr_lock' > powerpc-linux-ld: usb.c:(.text+0xce): undefined reference to > `cmxgcr_lock' > > >>> > >>> .config extract: > >>> > >>> # > >>> # NXP/Freescale QorIQ SoC drivers > >>> # > >>> # CONFIG_QUICC_ENGINE is not set > >>> CONFIG_QE_USB=y > >>> > >>> > >>> This is caused by (drivers/soc/fsl/qe/Kconfig): > >>> > >>> config QE_USB > >>> bool > >>> default y if USB_FSL_QE > >>> help > >>> QE USB Controller support > >>> > >>> which does not depend on QUICC_ENGINE, where the latter build > >>> provides the missing symbols. > >> > >> So QE_USB should depend on QUICC_ENGINE no? > > > > Yes, that would make sense, but I don't know enough about the > > hardware. I.e., could CONFIG_PPC_EP88XC have QE_USB without having a > > full QUICC_ENGINE? > > > > Kconfig says: > > config PPC_EP88XC >
Re: [PATCH V1] PCI/AER: Configure ECRC only AER is native
On Wed, Jan 11, 2023 at 01:42:21PM -0800, Sathyanarayanan Kuppuswamy wrote:
> On 1/11/23 12:31 PM, Vidya Sagar wrote:
> > As the ECRC configuration bits are part of AER registers, configure
> > ECRC only if AER is natively owned by the kernel.
>
> ecrc command line option takes "bios/on/off" as possible options. It
> does not clarify whether "on/off" choices can only be used if AER is
> owned by OS or it can override the ownership of ECRC configuration
> similar to pcie_ports=native option. Maybe that needs to be clarified.
Good point, what do you think of an update like this:
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index 6cfa6e3996cf..f7b40a439194 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -4296,7 +4296,9 @@
specified, e.g., 12@pci:8086:9c22:103c:198f
for 4096-byte alignment.
ecrc= Enable/disable PCIe ECRC (transaction layer
- end-to-end CRC checking).
+ end-to-end CRC checking). Only effective
+ if OS has native AER control (either granted by
+ ACPI _OSC or forced via "pcie_ports=native").
bios: Use BIOS/firmware settings. This is the
the default.
off: Turn ECRC off
I don't know whether the "ecrc=" parameter is really needed. If we
were adding it today, I would ask "why not enable ECRC wherever it is
supported?" If there are devices where it's broken, we could always
add quirks to disable it on a case-by-case basis.
But I think the patch below is the right thing to do for now. Vidya,
did you trip over an issue because of this, e.g., a conflict between
firmware use of AER and Linux use of it? If so, maybe we could
mention a symptom on the commit log. But my guess is you probably
found this by inspection.
Bjorn
> > Signed-off-by: Vidya Sagar
> > ---
> > drivers/pci/pcie/aer.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
> > index e2d8a74f83c3..730b47bdcdef 100644
> > --- a/drivers/pci/pcie/aer.c
> > +++ b/drivers/pci/pcie/aer.c
> > @@ -184,6 +184,9 @@ static int disable_ecrc_checking(struct pci_dev *dev)
> > */
> > void pcie_set_ecrc_checking(struct pci_dev *dev)
> > {
> > + if (!pcie_aer_is_native(dev))
> > + return;
> > +
> > switch (ecrc_policy) {
> > case ECRC_POLICY_DEFAULT:
> > return;
>
> --
> Sathyanarayanan Kuppuswamy
> Linux Kernel Developer
[PATCH V1] PCI/AER: Configure ECRC only AER is native
As the ECRC configuration bits are part of AER registers, configure
ECRC only if AER is natively owned by the kernel.
Signed-off-by: Vidya Sagar
---
drivers/pci/pcie/aer.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
index e2d8a74f83c3..730b47bdcdef 100644
--- a/drivers/pci/pcie/aer.c
+++ b/drivers/pci/pcie/aer.c
@@ -184,6 +184,9 @@ static int disable_ecrc_checking(struct pci_dev *dev)
*/
void pcie_set_ecrc_checking(struct pci_dev *dev)
{
+ if (!pcie_aer_is_native(dev))
+ return;
+
switch (ecrc_policy) {
case ECRC_POLICY_DEFAULT:
return;
--
2.17.1
[PATCH] modpost: support arbitrary symbol length in modversion
Currently modversion uses a fixed size array of size (64 - sizeof(long))
to store symbol names, thus placing a hard limit on length of symbols.
Rust symbols (which encodes crate and module names) can be quite a bit
longer. The length limit in kallsyms is increased to 512 for this reason.
It's a waste of space to simply expand the fixed array size to 512 in
modversion info entries. I therefore make it variably sized, with offset
to the next entry indicated by the initial "next" field.
In addition to supporting longer-than-56/60 byte symbols, this patch also
reduce the size for short symbols by getting rid of excessive 0 paddings.
There are still some zero paddings to ensure "next" and "crc" fields are
properly aligned.
This patch does have a tiny drawback that it makes ".mod.c" files generated
a bit less easy to read, as code like
"\x08\x00\x00\x00\x78\x56\x34\x12"
"symbol\0\0"
is generated as opposed to
{ 0x12345678, "symbol" },
because the structure is now variable-length. But hopefully nobody reads
the generated file :)
Link: b8a94bfb3395 ("kallsyms: increase maximum kernel symbol length to 512")
Link: https://github.com/Rust-for-Linux/linux/pull/379
Signed-off-by: Gary Guo
---
arch/powerpc/kernel/module_64.c | 3 ++-
include/linux/module.h | 6 --
kernel/module/version.c | 21 +
scripts/export_report.pl| 9 +
scripts/mod/modpost.c | 33 +++--
5 files changed, 43 insertions(+), 29 deletions(-)
diff --git a/arch/powerpc/kernel/module_64.c b/arch/powerpc/kernel/module_64.c
index ff045644f13f..eac23c11d579 100644
--- a/arch/powerpc/kernel/module_64.c
+++ b/arch/powerpc/kernel/module_64.c
@@ -236,10 +236,11 @@ static void dedotify_versions(struct modversion_info
*vers,
{
struct modversion_info *end;
- for (end = (void *)vers + size; vers < end; vers++)
+ for (end = (void *)vers + size; vers < end; vers = (void *)vers +
vers->next) {
if (vers->name[0] == '.') {
memmove(vers->name, vers->name+1, strlen(vers->name));
}
+ }
}
/*
diff --git a/include/linux/module.h b/include/linux/module.h
index 8c5909c0076c..37cb25af9099 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -34,8 +34,10 @@
#define MODULE_NAME_LEN MAX_PARAM_PREFIX_LEN
struct modversion_info {
- unsigned long crc;
- char name[MODULE_NAME_LEN];
+ /* Offset of the next modversion entry in relation to this one. */
+ u32 next;
+ u32 crc;
+ char name[0];
};
struct module;
diff --git a/kernel/module/version.c b/kernel/module/version.c
index 53f43ac5a73e..af7478dcc158 100644
--- a/kernel/module/version.c
+++ b/kernel/module/version.c
@@ -17,32 +17,29 @@ int check_version(const struct load_info *info,
{
Elf_Shdr *sechdrs = info->sechdrs;
unsigned int versindex = info->index.vers;
- unsigned int i, num_versions;
- struct modversion_info *versions;
+ struct modversion_info *versions, *end;
+ u32 crcval;
/* Exporting module didn't supply crcs? OK, we're already tainted. */
if (!crc)
return 1;
+ crcval = *crc;
/* No versions at all? modprobe --force does this. */
if (versindex == 0)
return try_to_force_load(mod, symname) == 0;
versions = (void *)sechdrs[versindex].sh_addr;
- num_versions = sechdrs[versindex].sh_size
- / sizeof(struct modversion_info);
+ end = (void *)versions + sechdrs[versindex].sh_size;
- for (i = 0; i < num_versions; i++) {
- u32 crcval;
-
- if (strcmp(versions[i].name, symname) != 0)
+ for (; versions < end; versions = (void *)versions + versions->next) {
+ if (strcmp(versions->name, symname) != 0)
continue;
- crcval = *crc;
- if (versions[i].crc == crcval)
+ if (versions->crc == crcval)
return 1;
- pr_debug("Found checksum %X vs module %lX\n",
-crcval, versions[i].crc);
+ pr_debug("Found checksum %X vs module %X\n",
+crcval, versions->crc);
goto bad_version;
}
diff --git a/scripts/export_report.pl b/scripts/export_report.pl
index feb3d5542a62..1117646f3141 100755
--- a/scripts/export_report.pl
+++ b/scripts/export_report.pl
@@ -116,18 +116,19 @@ foreach my $thismod (@allcfiles) {
while ( <$module> ) {
chomp;
if ($state == 0) {
- $state = 1 if ($_ =~ /static const struct
modversion_info/);
+ $state = 1 if ($_ =~ /static const char versions/);
next;
}
if ($state == 1) {
- $state = 2 if ($_ =~
[PATCH 1/1] ASoC: fsl_sai: Use dev_err_probe
This helps figuring out why the device probe is deferred, e.g. missing
FSL_EDMA driver.
Signed-off-by: Alexander Stein
---
Old:
root@ls1021:~# cat /sys/kernel/debug/devices_deferred
sound fsl-asoc-card: snd_soc_register_card failed: -517
2b5.sai
New:
root@ls1021:~# cat /sys/kernel/debug/devices_deferred
sound fsl-asoc-card: snd_soc_register_card failed: -517
2b5.sai fsl-sai: Registering PCM dmaengine failed
sound/soc/fsl/fsl_sai.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c
index 1c9be8a5dcb13..2a38e2bdf9893 100644
--- a/sound/soc/fsl/fsl_sai.c
+++ b/sound/soc/fsl/fsl_sai.c
@@ -1458,14 +1458,17 @@ static int fsl_sai_probe(struct platform_device *pdev)
if (sai->soc_data->use_imx_pcm) {
ret = imx_pcm_dma_init(pdev);
if (ret) {
+ dev_err_probe(dev, ret, "PCM DMA init failed\n");
if (!IS_ENABLED(CONFIG_SND_SOC_IMX_PCM_DMA))
dev_err(dev, "Error: You must enable the
imx-pcm-dma support!\n");
goto err_pm_get_sync;
}
} else {
ret = devm_snd_dmaengine_pcm_register(dev, NULL, 0);
- if (ret)
+ if (ret) {
+ dev_err_probe(dev, ret, "Registering PCM dmaengine
failed\n");
goto err_pm_get_sync;
+ }
}
ret = devm_snd_soc_register_component(dev, _component,
--
2.34.1
Re: [PATCH v2 01/16] of: device: make of_device_uevent_modalias() take a const device *
On 11/01/2023 17:26, Greg Kroah-Hartman wrote: On Wed, Jan 11, 2023 at 08:54:04AM -0600, Rob Herring wrote: On Wed, Jan 11, 2023 at 5:30 AM Greg Kroah-Hartman wrote: of_device_uevent_modalias() does not modify the device pointer passed to it, so mark it constant. In order to properly do this, a number of busses need to have a modalias function added as they were attempting to just point to of_device_uevent_modalias instead of their bus-specific modalias function. This is fine except if the prototype for a bus and device type modalias function diverges and then problems could happen. To prevent all of that, just wrap the call to of_device_uevent_modalias() directly for each bus and device type individually. Why not just put the wrapper function in the DT code instead of making 4 copies of it? I could, if you think that it would be better there instead of in each individual bus (like all of the other bus callbacks). This way each bus "owns" their implementation :) I'd vote for the generic wrapper instead of 4 similar wrapper. In the end, if of_device_uevent_modalias (or the bus callback) interface changes again for whatever reasons, there will be just a single place to fix rather than fixing 4 (or more) bus drivers. -- With best wishes Dmitry
Re: [PATCH V1] PCI/AER: Configure ECRC only AER is native
On 1/11/23 12:31 PM, Vidya Sagar wrote:
> As the ECRC configuration bits are part of AER registers, configure
> ECRC only if AER is natively owned by the kernel.
ecrc command line option takes "bios/on/off" as possible options. It
does not clarify whether "on/off" choices can only be used if AER is
owned by OS or it can override the ownership of ECRC configuration
similar to pcie_ports=native option. Maybe that needs to be clarified.
>
> Signed-off-by: Vidya Sagar
> ---
> drivers/pci/pcie/aer.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
> index e2d8a74f83c3..730b47bdcdef 100644
> --- a/drivers/pci/pcie/aer.c
> +++ b/drivers/pci/pcie/aer.c
> @@ -184,6 +184,9 @@ static int disable_ecrc_checking(struct pci_dev *dev)
> */
> void pcie_set_ecrc_checking(struct pci_dev *dev)
> {
> + if (!pcie_aer_is_native(dev))
> + return;
> +
> switch (ecrc_policy) {
> case ECRC_POLICY_DEFAULT:
> return;
--
Sathyanarayanan Kuppuswamy
Linux Kernel Developer
Re: [PATCH 13/41] mm: introduce vma->vm_flags modifier functions
On Wed, Jan 11, 2023 at 12:19 PM Davidlohr Bueso wrote: > > On Wed, 11 Jan 2023, Suren Baghdasaryan wrote: > > >On Wed, Jan 11, 2023 at 8:13 AM Davidlohr Bueso wrote: > >> > >> On Mon, 09 Jan 2023, Suren Baghdasaryan wrote: > >> > >> >To keep vma locking correctness when vm_flags are modified, add modifier > >> >functions to be used whenever flags are updated. > >> > >> How about moving this patch and the ones that follow out of this series, > >> into a preliminary patchset? It would reduce the amount of noise in the > >> per-vma lock changes, which would then only be adding the needed > >> vma_write_lock()ing. > > > >How about moving those prerequisite patches to the beginning of the > >patchset (before maple_tree RCU changes)? I feel like they do belong > >in the patchset because as a standalone patchset it would be unclear > >why I'm adding all these accessor functions and introducing this > >churn. Would that be acceptable? > > imo the abstraction of vm_flags handling is worth being standalone and is > easier to be picked up before a more complex locking scheme change. But > either way, it's up to you. I see your point. Ok, if you think it makes sense as a stand-alone patch I can post it separately in the next version. Thanks, Suren. > > Thanks, > Davidlohr > > -- > To unsubscribe from this group and stop receiving emails from it, send an > email to kernel-team+unsubscr...@android.com. >
Re: [PATCH 13/41] mm: introduce vma->vm_flags modifier functions
On Wed, 11 Jan 2023, Suren Baghdasaryan wrote: On Wed, Jan 11, 2023 at 8:13 AM Davidlohr Bueso wrote: On Mon, 09 Jan 2023, Suren Baghdasaryan wrote: >To keep vma locking correctness when vm_flags are modified, add modifier >functions to be used whenever flags are updated. How about moving this patch and the ones that follow out of this series, into a preliminary patchset? It would reduce the amount of noise in the per-vma lock changes, which would then only be adding the needed vma_write_lock()ing. How about moving those prerequisite patches to the beginning of the patchset (before maple_tree RCU changes)? I feel like they do belong in the patchset because as a standalone patchset it would be unclear why I'm adding all these accessor functions and introducing this churn. Would that be acceptable? imo the abstraction of vm_flags handling is worth being standalone and is easier to be picked up before a more complex locking scheme change. But either way, it's up to you. Thanks, Davidlohr
Re: [PATCH v4] net: wan: Add checks for NULL for utdm in undo_uhdlc_init and unmap_si_regs
On Wed, 11 Jan 2023 22:55:33 +0300 Esina Ekaterina wrote:
> Signed-off-by: Esina Ekaterina
> ---
This --- is still indented.
On top of that please tag the patch for the tree to which networking
maintainers apply fixes (by specifying [PATCH net v5] instead just
[PATCH v5] in the subject).
And add a Fixes tag. If the bug dates all the way back to the start of
the git era add:
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
otherwise use the commit which added the buggy code.
[PATCH v4] net: wan: Add checks for NULL for utdm in undo_uhdlc_init and unmap_si_regs
If uhdlc_priv_tsa != 1 then utdm is not initialized. And if ret != NULL then goto undo_uhdlc_init, where utdm is dereferenced. Same if dev == NULL. Found by Astra Linux on behalf of Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Esina Ekaterina --- v4: Fix style v3: Remove braces v2: Add check for NULL for unmap_si_regs --- drivers/net/wan/fsl_ucc_hdlc.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/net/wan/fsl_ucc_hdlc.c b/drivers/net/wan/fsl_ucc_hdlc.c index 22edea6ca4b8..1c53b5546927 100644 --- a/drivers/net/wan/fsl_ucc_hdlc.c +++ b/drivers/net/wan/fsl_ucc_hdlc.c @@ -1243,9 +1243,11 @@ static int ucc_hdlc_probe(struct platform_device *pdev) free_dev: free_netdev(dev); undo_uhdlc_init: - iounmap(utdm->siram); + if (utdm) + iounmap(utdm->siram); unmap_si_regs: - iounmap(utdm->si_regs); + if (utdm) + iounmap(utdm->si_regs); free_utdm: if (uhdlc_priv->tsa) kfree(utdm); -- 2.39.0
Re: usb.c:undefined reference to `qe_immr'
Le 11/01/2023 à 17:01, Randy Dunlap a écrit :
>
>
> On 1/10/23 23:39, Michael Ellerman wrote:
>> Randy Dunlap writes:
>>> [adding Cc's]
>>>
>>>
>>> On 1/9/23 23:59, kernel test robot wrote:
Hi Masahiro,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 5a41237ad1d4b62008f93163af1d9b1da90729d8
commit: 7b4537199a4a8480b8c3ba37a2d44765ce76cd9b kbuild: link symbol CRCs
at final link, removing CONFIG_MODULE_REL_CRCS
date: 8 months ago
config: powerpc-randconfig-r026-20230110
compiler: powerpc-linux-gcc (GCC) 12.1.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross
-O ~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7b4537199a4a8480b8c3ba37a2d44765ce76cd9b
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 7b4537199a4a8480b8c3ba37a2d44765ce76cd9b
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross
W=1 O=build_dir ARCH=powerpc olddefconfig
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross
W=1 O=build_dir ARCH=powerpc SHELL=/bin/bash
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot
All errors (new ones prefixed by >>):
powerpc-linux-ld: powerpc-linux-ld: DWARF error: could not find abbrev
number 74
drivers/soc/fsl/qe/usb.o: in function `qe_usb_clock_set':
>> usb.c:(.text+0x1e): undefined reference to `qe_immr'
>> powerpc-linux-ld: usb.c:(.text+0x2a): undefined reference to `qe_immr'
>> powerpc-linux-ld: usb.c:(.text+0xbc): undefined reference to `qe_setbrg'
>> powerpc-linux-ld: usb.c:(.text+0xca): undefined reference to
>> `cmxgcr_lock'
powerpc-linux-ld: usb.c:(.text+0xce): undefined reference to
`cmxgcr_lock'
>>>
>>> .config extract:
>>>
>>> #
>>> # NXP/Freescale QorIQ SoC drivers
>>> #
>>> # CONFIG_QUICC_ENGINE is not set
>>> CONFIG_QE_USB=y
>>>
>>>
>>> This is caused by (drivers/soc/fsl/qe/Kconfig):
>>>
>>> config QE_USB
>>> bool
>>> default y if USB_FSL_QE
>>> help
>>> QE USB Controller support
>>>
>>> which does not depend on QUICC_ENGINE, where the latter build provides
>>> the missing symbols.
>>
>> So QE_USB should depend on QUICC_ENGINE no?
>
> Yes, that would make sense, but I don't know enough about the
> hardware. I.e., could CONFIG_PPC_EP88XC have QE_USB without having
> a full QUICC_ENGINE?
>
Kconfig says:
config PPC_EP88XC
bool "Embedded Planet EP88xC (a.k.a. CWH-PPC-885XN-VE)"
select CPM1
help
This enables support for the Embedded Planet EP88xC board.
This board is also resold by Freescale as the QUICCStart
MPC885 Evaluation System and/or the CWH-PPC-885XN-VE.
MPC885 has an USB controller, but I was not aware Linux had any USB
driver for the 885. Need to dig into history. Was initialy added by
commit 3948f0e0c999 ("usb: add Freescale QE/CPM USB peripheral
controller driver"), it explicitely says it should work on CPM.
Christophe
Re: [PATCH v3] net: wan: Add checks for NULL for utdm in undo_uhdlc_init and unmap_si_regs
On Wed, 11 Jan 2023 12:05:03 +0300 Esina Ekaterina wrote: > Subject: [PATCH v3] net: wan: Add checks for NULL for utdm in > undo_uhdlc_init and unmap_si_regs net: wan: prevent null-deref on error path for non-tdm case > If uhdlc_priv_tsa != 1 then utdm is not initialized. > And if ret != NULL then goto undo_uhdlc_init, where > utdm is dereferenced. Same if dev == NULL. > > Found by Linux Verification Center (linuxtesting.org) with SVACE. I did the indentation to make the content stand out in the email, there should be no indentation in the actual msg, sorry. > --- a/drivers/net/wan/fsl_ucc_hdlc.c > +++ b/drivers/net/wan/fsl_ucc_hdlc.c > @@ -1243,9 +1243,11 @@ static int ucc_hdlc_probe(struct platform_device *pdev) > free_dev: > free_netdev(dev); > undo_uhdlc_init: > - iounmap(utdm->siram); > + if (utdm != NULL) and here just: if (utdm) comparing to NULL or zero is less idiomatic in kernel C. > + iounmap(utdm->siram); > unmap_si_regs: > - iounmap(utdm->si_regs); > + if (utdm != NULL) > + iounmap(utdm->si_regs);
Re: [PATCH 08/41] mm: introduce CONFIG_PER_VMA_LOCK
On Wed, Jan 11, 2023 at 10:03 AM Michal Hocko wrote: > > On Wed 11-01-23 09:49:08, Suren Baghdasaryan wrote: > > On Wed, Jan 11, 2023 at 9:37 AM Michal Hocko wrote: > > > > > > On Wed 11-01-23 09:04:41, Suren Baghdasaryan wrote: > > > > On Wed, Jan 11, 2023 at 8:44 AM Michal Hocko wrote: > > > > > > > > > > On Wed 11-01-23 08:28:49, Suren Baghdasaryan wrote: > > > > > [...] > > > > > > Anyhow. Sounds like the overhead of the current design is small > > > > > > enough > > > > > > to remove CONFIG_PER_VMA_LOCK and let it depend only on architecture > > > > > > support? > > > > > > > > > > Yes. Further optimizations can be done on top. Let's not over optimize > > > > > at this stage. > > > > > > > > Sure, I won't optimize any further. > > > > Just to expand on your question. Original design would be problematic > > > > for embedded systems like Android. It notoriously has a high number of > > > > VMAs due to anonymous VMAs being named, which prevents them from > > > > merging. > > > > > > What is the usual number of VMAs in that environment? > > > > I've seen some games which had over 4000 VMAs but that's on the upper > > side. In my calculations I used 4 VMAs as a ballpark number and > > rough calculations before size optimization would increase memory > > consumption by ~2M (depending on the lock placement in vm_area_struct > > it would vary a bit). In Android, the performance team flags any > > change that exceeds 500KB, so it would raise questions. > > Thanks, that is a useful information! This is just slightly off-topic > but I ak wondering how much memory those vma names consume. Are there > that many unique names or they just happen to be alternating so that > neighboring ones tend to be different. Good question. I don't have the ready answer to that but will try to collect some stats. I know that many names are standardized but haven't looked at how they are distributed in the address space. Will followup once I collect the data. Thanks, Suren. > -- > Michal Hocko > SUSE Labs
Re: [PATCH 08/41] mm: introduce CONFIG_PER_VMA_LOCK
On Wed 11-01-23 09:49:08, Suren Baghdasaryan wrote: > On Wed, Jan 11, 2023 at 9:37 AM Michal Hocko wrote: > > > > On Wed 11-01-23 09:04:41, Suren Baghdasaryan wrote: > > > On Wed, Jan 11, 2023 at 8:44 AM Michal Hocko wrote: > > > > > > > > On Wed 11-01-23 08:28:49, Suren Baghdasaryan wrote: > > > > [...] > > > > > Anyhow. Sounds like the overhead of the current design is small enough > > > > > to remove CONFIG_PER_VMA_LOCK and let it depend only on architecture > > > > > support? > > > > > > > > Yes. Further optimizations can be done on top. Let's not over optimize > > > > at this stage. > > > > > > Sure, I won't optimize any further. > > > Just to expand on your question. Original design would be problematic > > > for embedded systems like Android. It notoriously has a high number of > > > VMAs due to anonymous VMAs being named, which prevents them from > > > merging. > > > > What is the usual number of VMAs in that environment? > > I've seen some games which had over 4000 VMAs but that's on the upper > side. In my calculations I used 4 VMAs as a ballpark number and > rough calculations before size optimization would increase memory > consumption by ~2M (depending on the lock placement in vm_area_struct > it would vary a bit). In Android, the performance team flags any > change that exceeds 500KB, so it would raise questions. Thanks, that is a useful information! This is just slightly off-topic but I ak wondering how much memory those vma names consume. Are there that many unique names or they just happen to be alternating so that neighboring ones tend to be different. -- Michal Hocko SUSE Labs
Re: [PATCH 08/41] mm: introduce CONFIG_PER_VMA_LOCK
On Wed, Jan 11, 2023 at 9:37 AM Michal Hocko wrote: > > On Wed 11-01-23 09:04:41, Suren Baghdasaryan wrote: > > On Wed, Jan 11, 2023 at 8:44 AM Michal Hocko wrote: > > > > > > On Wed 11-01-23 08:28:49, Suren Baghdasaryan wrote: > > > [...] > > > > Anyhow. Sounds like the overhead of the current design is small enough > > > > to remove CONFIG_PER_VMA_LOCK and let it depend only on architecture > > > > support? > > > > > > Yes. Further optimizations can be done on top. Let's not over optimize > > > at this stage. > > > > Sure, I won't optimize any further. > > Just to expand on your question. Original design would be problematic > > for embedded systems like Android. It notoriously has a high number of > > VMAs due to anonymous VMAs being named, which prevents them from > > merging. > > What is the usual number of VMAs in that environment? I've seen some games which had over 4000 VMAs but that's on the upper side. In my calculations I used 4 VMAs as a ballpark number and rough calculations before size optimization would increase memory consumption by ~2M (depending on the lock placement in vm_area_struct it would vary a bit). In Android, the performance team flags any change that exceeds 500KB, so it would raise questions. > > -- > Michal Hocko > SUSE Labs
Re: [PATCH 08/41] mm: introduce CONFIG_PER_VMA_LOCK
On Wed 11-01-23 09:04:41, Suren Baghdasaryan wrote: > On Wed, Jan 11, 2023 at 8:44 AM Michal Hocko wrote: > > > > On Wed 11-01-23 08:28:49, Suren Baghdasaryan wrote: > > [...] > > > Anyhow. Sounds like the overhead of the current design is small enough > > > to remove CONFIG_PER_VMA_LOCK and let it depend only on architecture > > > support? > > > > Yes. Further optimizations can be done on top. Let's not over optimize > > at this stage. > > Sure, I won't optimize any further. > Just to expand on your question. Original design would be problematic > for embedded systems like Android. It notoriously has a high number of > VMAs due to anonymous VMAs being named, which prevents them from > merging. What is the usual number of VMAs in that environment? -- Michal Hocko SUSE Labs
Re: [PATCH 13/41] mm: introduce vma->vm_flags modifier functions
On Wed, Jan 11, 2023 at 8:13 AM Davidlohr Bueso wrote: > > On Mon, 09 Jan 2023, Suren Baghdasaryan wrote: > > >To keep vma locking correctness when vm_flags are modified, add modifier > >functions to be used whenever flags are updated. > > How about moving this patch and the ones that follow out of this series, > into a preliminary patchset? It would reduce the amount of noise in the > per-vma lock changes, which would then only be adding the needed > vma_write_lock()ing. How about moving those prerequisite patches to the beginning of the patchset (before maple_tree RCU changes)? I feel like they do belong in the patchset because as a standalone patchset it would be unclear why I'm adding all these accessor functions and introducing this churn. Would that be acceptable? > > Thanks, > Davidlohr > > -- > To unsubscribe from this group and stop receiving emails from it, send an > email to kernel-team+unsubscr...@android.com. >
Re: [PATCH v2 06/10] soc: fsl: qe: Add support for QMC
Le 11/01/2023 à 16:40, Herve Codina a écrit :
> Hi Christophe,
> On Wed, 11 Jan 2023 13:58:03 +
> Christophe Leroy wrote:
>
>> Le 06/01/2023 à 17:37, Herve Codina a écrit :
>>> The QMC (QUICC Multichannel Controller) is available on some
>>> PowerQUICC SoC such as the MPC885 or MPC866.
>>
>> Same, that's QMC for CPM for the time being, should that be made clear
>> in the subject ?
>
> Also same answer:
> Will changing the subject be enough or do I need to move it to new
> created drivers/soc/fsl/cpm/ directory ?
>
>>
>> QE also has QMC and this driver might be used for QE QMC as well with
>> some enhancement, maybe that could be explained here ?
>
> Yes and we plan to have it working on QE too.
>
> What do you think if I add the following:
>The QMC is also available on some Quicc Engine SoC.
>This current version support CPM1 SoC only. Some
>enhancement are needed to support Quicc Engine SoC.
>
That's look good.
>>
>> I see you are using in_be16(), out_be16() etc
>> That's specific to powerpc arch, maybe it is better to use ioread16be,
>> iowrite16be() etc
>> See commit 3f39f38ea91d ("soc: fsl: qe: replace qe_io{read,write}*
>> wrappers by generic io{read,write}*") and commit 6ac9b61786cc ("soc:
>> fsl: qe: introduce qe_io{read,write}* wrappers") for information.
>
> You're right.
> I will switch to io{read,write}{16,32}be.
>
> I prefer avoid the use of qe_* wrappers as the driver is not
> (yet) compatible with QE.
By the way that was the purpose of commit 3f39f38ea91d ("soc: fsl: qe:
replace qe_io{read,write}* wrappers by generic io{read,write}*"),
replace qe_* wrappers by direct use of io{read,write}{16,32}be
So yes, using io{read,write}{16,32}be directly is preferable.
>
>>
>>>
>>> It emulates up to 64 channels within one serial controller
>>> using the same TDM physical interface routed from the TSA.
>>>
>>> Signed-off-by: Herve Codina
>>
>> In some places, you comments use the network style, not the generic style.
>
> I will fix them.
>
>>
>> Christophe
>
> Thanks for the review,
> Hervé
>
Re: [PATCH v3 07/13] tty: Convert ->dtr_rts() to take bool argument
On Wed, Jan 11, 2023 at 04:23:25PM +0200, Ilpo Järvinen wrote: > Convert the raise/on parameter in ->dtr_rts() to bool through the > callchain. The parameter is used like bool. In USB serial, there > remains a few implicit bool -> larger type conversions because some > devices use u8 in their control messages. > > In moxa_tiocmget(), dtr variable was reused for line status which > requires int so use a separate variable for status. > > Reviewed-by: Jiri Slaby > Signed-off-by: Ilpo Järvinen > --- > drivers/char/pcmcia/synclink_cs.c| 4 +-- > drivers/mmc/core/sdio_uart.c | 4 +-- > drivers/staging/greybus/uart.c | 2 +- > drivers/tty/amiserial.c | 2 +- > drivers/tty/hvc/hvc_console.c| 4 +-- > drivers/tty/hvc/hvc_console.h| 2 +- > drivers/tty/hvc/hvc_iucv.c | 4 +-- > drivers/tty/moxa.c | 54 ++-- > drivers/tty/mxser.c | 2 +- > drivers/tty/n_gsm.c | 2 +- > drivers/tty/serial/serial_core.c | 8 ++--- > drivers/tty/synclink_gt.c| 2 +- > drivers/tty/tty_port.c | 4 +-- > drivers/usb/class/cdc-acm.c | 2 +- > drivers/usb/serial/ch341.c | 2 +- > drivers/usb/serial/cp210x.c | 4 +-- > drivers/usb/serial/cypress_m8.c | 6 ++-- > drivers/usb/serial/digi_acceleport.c | 6 ++-- > drivers/usb/serial/f81232.c | 2 +- > drivers/usb/serial/f81534.c | 2 +- > drivers/usb/serial/ftdi_sio.c| 2 +- > drivers/usb/serial/ipw.c | 2 +- > drivers/usb/serial/keyspan.c | 2 +- > drivers/usb/serial/keyspan_pda.c | 2 +- > drivers/usb/serial/mct_u232.c| 4 +-- > drivers/usb/serial/mxuport.c | 2 +- > drivers/usb/serial/pl2303.c | 2 +- > drivers/usb/serial/quatech2.c| 2 +- > drivers/usb/serial/sierra.c | 2 +- > drivers/usb/serial/spcp8x5.c | 2 +- > drivers/usb/serial/ssu100.c | 2 +- > drivers/usb/serial/upd78f0730.c | 6 ++-- > drivers/usb/serial/usb-serial.c | 2 +- > drivers/usb/serial/usb-wwan.h| 2 +- > drivers/usb/serial/usb_wwan.c| 2 +- > drivers/usb/serial/xr_serial.c | 6 ++-- > include/linux/tty_port.h | 4 +-- > include/linux/usb/serial.h | 2 +- > 38 files changed, 84 insertions(+), 82 deletions(-) Same here. No need to lump the tty-port changes with USB-serial changes. Johan
Re: [PATCH v2 02/10] soc: fsl: qe: Add support for TSA
Le 11/01/2023 à 16:06, Herve Codina a écrit :
> Hi Christophe,
>
> On Wed, 11 Jan 2023 13:47:23 +
> Christophe Leroy wrote:
>
>> Le 06/01/2023 à 17:37, Herve Codina a écrit :
>>> The TSA (Time Slot Assigner) is available in some
>>> PowerQUICC SoC such as the MPC885 or MPC866.
>>>
>>> Its purpose is to route some TDM time-slots to other
>>> internal serial controllers.
>>
>> Is the subject correct ? As far as I understand this patch adds support
>> for the TSA on the CPM (exactly on CPM1), not on the QE.
>
> Yes exactly, it is a CPM1 support (kind of previous version of QE).
>
> Do you think that fixing the subject is enough or do I need also
> to create a new directory drivers/soc/fsl/cpm/ and move these drivers
> (TSA and QMC) in this new directory.
I think fixing the subject should be good enough.
Today we already have in that drivers/soc/fsl/qe/ directory some code
which is common between CPM and QE, mainly in qe_common.c
Not sure qe_common.c is the best name ever, but it has been given that
name in commit 1291e49e8937 ("QE/CPM: move muram management functions to
qe_common")
So let's things as they are, just be precise in the subject, and if the
final intention is to have some TSA common to CPM and QE, let's just
call it tsa.c . If it's dedicated to CPM at the end, then maybe call it
cpm-tsa.c.
Maybe one day we should rename drivers/soc/fsl/qe/ to
drivers/soc/fsl/cpm-qe/
>
> The alternative could be to leave this driver in drivers/soc/qe/ and
> rename it to cpm-tsa.c.
>
> For information, we have some plan to have this driver working
> with QE (not done yet).
>
>>
>> By the way, there are already some embryo for handling TSA on QE in
>> drivers/soc/fsl/qe/qe-tdm.c
>
> Yes but this can be seen as an extension only used by
> drivers/net/wan/fsl_ucc_hdlc.c and it supports QE only.
>
> Not sure that qe-tdm.c will fit well if several other
> drivers instances use it.
Fair enough.
>
>>
>>>
>>> Signed-off-by: Herve Codina
>>
>> Christophe
>
> Thanks for the review,
> Hervé
>
Re: [PATCH 08/41] mm: introduce CONFIG_PER_VMA_LOCK
On Wed, Jan 11, 2023 at 8:44 AM Michal Hocko wrote: > > On Wed 11-01-23 08:28:49, Suren Baghdasaryan wrote: > [...] > > Anyhow. Sounds like the overhead of the current design is small enough > > to remove CONFIG_PER_VMA_LOCK and let it depend only on architecture > > support? > > Yes. Further optimizations can be done on top. Let's not over optimize > at this stage. Sure, I won't optimize any further. Just to expand on your question. Original design would be problematic for embedded systems like Android. It notoriously has a high number of VMAs due to anonymous VMAs being named, which prevents them from merging. 2M per process increase would raise questions, therefore I felt the need for optimizing the memory overhead which is done in the last patch. Thanks for the feedback! > -- > Michal Hocko > SUSE Labs
Re: [PATCH v3 11/13] tty/serial: Call ->dtr_rts() parameter active consistently
On Wed, Jan 11, 2023 at 04:23:29PM +0200, Ilpo Järvinen wrote:
> Convert various parameter names for ->dtr_rts() and related functions
> from onoff, on, and raise to active.
>
> Reviewed-by: Jiri Slaby
> Signed-off-by: Ilpo Järvinen
> ---
> drivers/char/pcmcia/synclink_cs.c | 6 +++---
> drivers/mmc/core/sdio_uart.c | 6 +++---
> drivers/staging/greybus/uart.c| 4 ++--
> drivers/tty/amiserial.c | 4 ++--
> drivers/tty/hvc/hvc_console.h | 2 +-
> drivers/tty/hvc/hvc_iucv.c| 6 +++---
> drivers/tty/mxser.c | 4 ++--
> drivers/tty/n_gsm.c | 4 ++--
> drivers/tty/serial/serial_core.c | 8
> drivers/tty/synclink_gt.c | 4 ++--
> include/linux/tty_port.h | 4 ++--
> include/linux/usb/serial.h| 2 +-
> 12 files changed, 27 insertions(+), 27 deletions(-)
> diff --git a/include/linux/tty_port.h b/include/linux/tty_port.h
> index c44e489de0ff..edf685a24f7c 100644
> --- a/include/linux/tty_port.h
> +++ b/include/linux/tty_port.h
> @@ -16,7 +16,7 @@ struct tty_struct;
> /**
> * struct tty_port_operations -- operations on tty_port
> * @carrier_raised: return true if the carrier is raised on @port
> - * @dtr_rts: raise the DTR line if @raise is true, otherwise lower DTR
> + * @dtr_rts: raise the DTR line if @active is true, otherwise lower DTR
> * @shutdown: called when the last close completes or a hangup finishes IFF
> the
> * port was initialized. Do not use to free resources. Turn off the device
> * only. Called under the port mutex to serialize against @activate and
> @@ -32,7 +32,7 @@ struct tty_struct;
> */
> struct tty_port_operations {
> bool (*carrier_raised)(struct tty_port *port);
> - void (*dtr_rts)(struct tty_port *port, bool raise);
> + void (*dtr_rts)(struct tty_port *port, bool active);
> void (*shutdown)(struct tty_port *port);
> int (*activate)(struct tty_port *port, struct tty_struct *tty);
> void (*destruct)(struct tty_port *port);
> diff --git a/include/linux/usb/serial.h b/include/linux/usb/serial.h
> index bad343c5e8a7..33afd9f3ebbe 100644
> --- a/include/linux/usb/serial.h
> +++ b/include/linux/usb/serial.h
> @@ -292,7 +292,7 @@ struct usb_serial_driver {
> struct serial_icounter_struct *icount);
> /* Called by the tty layer for port level work. There may or may not
> be an attached tty at this point */
> - void (*dtr_rts)(struct usb_serial_port *port, bool on);
> + void (*dtr_rts)(struct usb_serial_port *port, bool active);
This is not a tty_port callback so this change does not belong in this
patch.
> bool (*carrier_raised)(struct usb_serial_port *port);
> /* Called by the usb serial hooks to allow the user to rework the
> termios state */
Johan
Re: [PATCH 08/41] mm: introduce CONFIG_PER_VMA_LOCK
On Wed 11-01-23 08:28:49, Suren Baghdasaryan wrote: [...] > Anyhow. Sounds like the overhead of the current design is small enough > to remove CONFIG_PER_VMA_LOCK and let it depend only on architecture > support? Yes. Further optimizations can be done on top. Let's not over optimize at this stage. -- Michal Hocko SUSE Labs
Re: [PATCH 08/41] mm: introduce CONFIG_PER_VMA_LOCK
On Wed, Jan 11, 2023 at 2:03 AM David Laight wrote: > > From: Ingo Molnar > > Sent: 11 January 2023 09:54 > > > > * Michal Hocko wrote: > > > > > On Tue 10-01-23 16:44:42, Suren Baghdasaryan wrote: > > > > On Tue, Jan 10, 2023 at 4:39 PM Davidlohr Bueso > > > > wrote: > > > > > > > > > > On Mon, 09 Jan 2023, Suren Baghdasaryan wrote: > > > > > > > > > > >This configuration variable will be used to build the support for VMA > > > > > >locking during page fault handling. > > > > > > > > > > > >This is enabled by default on supported architectures with SMP and > > > > > >MMU > > > > > >set. > > > > > > > > > > > >The architecture support is needed since the page fault handler is > > > > > >called > > > > > >from the architecture's page faulting code which needs modifications > > > > > >to > > > > > >handle faults under VMA lock. > > > > > > > > > > I don't think that per-vma locking should be something that is > > > > > user-configurable. > > > > > It should just be depdendant on the arch. So maybe just remove > > > > > CONFIG_PER_VMA_LOCK? > > > > > > > > Thanks for the suggestion! I would be happy to make that change if > > > > there are no objections. I think the only pushback might have been the > > > > vma size increase but with the latest optimization in the last patch > > > > maybe that's less of an issue? > > > > > > Has vma size ever been a real problem? Sure there might be a lot of those > > > but your patch increases it by rwsem (without the last patch) which is > > > something like 40B on top of 136B vma so we are talking about 400B in > > > total which even with wild mapcount limits shouldn't really be > > > prohibitive. With a default map count limit we are talking about 2M > > > increase at most (per address space). > > > > > > Or are you aware of any specific usecases where vma size is a real > > > problem? Well, when fixing the cacheline bouncing problem in the initial design I was adding 44 bytes to 152-byte vm_area_struct (CONFIG_NUMA enabled) and pushing it just above 192 bytes while allocating these structures from cache-aligned slab (keeping the lock in a separate cacheline to prevent cacheline bouncing). That would use the whole 256 bytes per VMA and it did make me nervous. The current design with no need to cache-align vm_area_structs and with 44-byte overhead trimmed down to 16 bytes seems much more palatable. > > > > 40 bytes for the rwsem, plus the patch also adds a 32-bit sequence counter: > > > > + int vm_lock_seq; > > + struct rw_semaphore lock; > > > > So it's +44 bytes. Correct. > > Depend in whether vm_lock_seq goes into a padding hole or not > it will be 40 or 48 bytes. > > But if these structures are allocated individually (not an array) > then it depends on how may items kmalloc() fits into a page (or 2,4). Yep. Depends on how we arrange the fields. Anyhow. Sounds like the overhead of the current design is small enough to remove CONFIG_PER_VMA_LOCK and let it depend only on architecture support? Thanks, Suren. > > David > > - > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 > 1PT, UK > Registration No: 1397386 (Wales) >
Re: [PATCH 13/41] mm: introduce vma->vm_flags modifier functions
On Mon, 09 Jan 2023, Suren Baghdasaryan wrote: To keep vma locking correctness when vm_flags are modified, add modifier functions to be used whenever flags are updated. How about moving this patch and the ones that follow out of this series, into a preliminary patchset? It would reduce the amount of noise in the per-vma lock changes, which would then only be adding the needed vma_write_lock()ing. Thanks, Davidlohr
Re: usb.c:undefined reference to `qe_immr'
On 1/10/23 23:39, Michael Ellerman wrote: > Randy Dunlap writes: >> [adding Cc's] >> >> >> On 1/9/23 23:59, kernel test robot wrote: >>> Hi Masahiro, >>> >>> FYI, the error/warning still remains. >>> >>> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git >>> master >>> head: 5a41237ad1d4b62008f93163af1d9b1da90729d8 >>> commit: 7b4537199a4a8480b8c3ba37a2d44765ce76cd9b kbuild: link symbol CRCs >>> at final link, removing CONFIG_MODULE_REL_CRCS >>> date: 8 months ago >>> config: powerpc-randconfig-r026-20230110 >>> compiler: powerpc-linux-gcc (GCC) 12.1.0 >>> reproduce (this is a W=1 build): >>> wget >>> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O >>> ~/bin/make.cross >>> chmod +x ~/bin/make.cross >>> # >>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7b4537199a4a8480b8c3ba37a2d44765ce76cd9b >>> git remote add linus >>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git >>> git fetch --no-tags linus master >>> git checkout 7b4537199a4a8480b8c3ba37a2d44765ce76cd9b >>> # save the config file >>> mkdir build_dir && cp config build_dir/.config >>> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1 >>> O=build_dir ARCH=powerpc olddefconfig >>> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1 >>> O=build_dir ARCH=powerpc SHELL=/bin/bash >>> >>> If you fix the issue, kindly add following tag where applicable >>> | Reported-by: kernel test robot >>> >>> All errors (new ones prefixed by >>): >>> >>>powerpc-linux-ld: powerpc-linux-ld: DWARF error: could not find abbrev >>> number 74 >>>drivers/soc/fsl/qe/usb.o: in function `qe_usb_clock_set': > usb.c:(.text+0x1e): undefined reference to `qe_immr' > powerpc-linux-ld: usb.c:(.text+0x2a): undefined reference to `qe_immr' > powerpc-linux-ld: usb.c:(.text+0xbc): undefined reference to `qe_setbrg' > powerpc-linux-ld: usb.c:(.text+0xca): undefined reference to `cmxgcr_lock' >>>powerpc-linux-ld: usb.c:(.text+0xce): undefined reference to >>> `cmxgcr_lock' >>> >> >> .config extract: >> >> # >> # NXP/Freescale QorIQ SoC drivers >> # >> # CONFIG_QUICC_ENGINE is not set >> CONFIG_QE_USB=y >> >> >> This is caused by (drivers/soc/fsl/qe/Kconfig): >> >> config QE_USB >> bool >> default y if USB_FSL_QE >> help >>QE USB Controller support >> >> which does not depend on QUICC_ENGINE, where the latter build provides >> the missing symbols. > > So QE_USB should depend on QUICC_ENGINE no? Yes, that would make sense, but I don't know enough about the hardware. I.e., could CONFIG_PPC_EP88XC have QE_USB without having a full QUICC_ENGINE? thanks. -- ~Randy
Re: [PATCH v2 06/10] soc: fsl: qe: Add support for QMC
Hi Christophe,
On Wed, 11 Jan 2023 13:58:03 +
Christophe Leroy wrote:
> Le 06/01/2023 à 17:37, Herve Codina a écrit :
> > The QMC (QUICC Multichannel Controller) is available on some
> > PowerQUICC SoC such as the MPC885 or MPC866.
>
> Same, that's QMC for CPM for the time being, should that be made clear
> in the subject ?
Also same answer:
Will changing the subject be enough or do I need to move it to new
created drivers/soc/fsl/cpm/ directory ?
>
> QE also has QMC and this driver might be used for QE QMC as well with
> some enhancement, maybe that could be explained here ?
Yes and we plan to have it working on QE too.
What do you think if I add the following:
The QMC is also available on some Quicc Engine SoC.
This current version support CPM1 SoC only. Some
enhancement are needed to support Quicc Engine SoC.
>
> I see you are using in_be16(), out_be16() etc
> That's specific to powerpc arch, maybe it is better to use ioread16be,
> iowrite16be() etc
> See commit 3f39f38ea91d ("soc: fsl: qe: replace qe_io{read,write}*
> wrappers by generic io{read,write}*") and commit 6ac9b61786cc ("soc:
> fsl: qe: introduce qe_io{read,write}* wrappers") for information.
You're right.
I will switch to io{read,write}{16,32}be.
I prefer avoid the use of qe_* wrappers as the driver is not
(yet) compatible with QE.
>
> >
> > It emulates up to 64 channels within one serial controller
> > using the same TDM physical interface routed from the TSA.
> >
> > Signed-off-by: Herve Codina
>
> In some places, you comments use the network style, not the generic style.
I will fix them.
>
> Christophe
Thanks for the review,
Hervé
--
Hervé Codina, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Re: [PATCH v2 01/16] of: device: make of_device_uevent_modalias() take a const device *
On Wed, Jan 11, 2023 at 08:54:04AM -0600, Rob Herring wrote: > On Wed, Jan 11, 2023 at 5:30 AM Greg Kroah-Hartman > wrote: > > > > of_device_uevent_modalias() does not modify the device pointer passed to > > it, so mark it constant. In order to properly do this, a number of > > busses need to have a modalias function added as they were attempting to > > just point to of_device_uevent_modalias instead of their bus-specific > > modalias function. This is fine except if the prototype for a bus and > > device type modalias function diverges and then problems could happen. To > > prevent all of that, just wrap the call to of_device_uevent_modalias() > > directly for each bus and device type individually. > > Why not just put the wrapper function in the DT code instead of making > 4 copies of it? I could, if you think that it would be better there instead of in each individual bus (like all of the other bus callbacks). This way each bus "owns" their implementation :) thanks, greg k-h
Re: [PATCH v2 02/10] soc: fsl: qe: Add support for TSA
Hi Christophe, On Wed, 11 Jan 2023 13:47:23 + Christophe Leroy wrote: > Le 06/01/2023 à 17:37, Herve Codina a écrit : > > The TSA (Time Slot Assigner) is available in some > > PowerQUICC SoC such as the MPC885 or MPC866. > > > > Its purpose is to route some TDM time-slots to other > > internal serial controllers. > > Is the subject correct ? As far as I understand this patch adds support > for the TSA on the CPM (exactly on CPM1), not on the QE. Yes exactly, it is a CPM1 support (kind of previous version of QE). Do you think that fixing the subject is enough or do I need also to create a new directory drivers/soc/fsl/cpm/ and move these drivers (TSA and QMC) in this new directory. The alternative could be to leave this driver in drivers/soc/qe/ and rename it to cpm-tsa.c. For information, we have some plan to have this driver working with QE (not done yet). > > By the way, there are already some embryo for handling TSA on QE in > drivers/soc/fsl/qe/qe-tdm.c Yes but this can be seen as an extension only used by drivers/net/wan/fsl_ucc_hdlc.c and it supports QE only. Not sure that qe-tdm.c will fit well if several other drivers instances use it. > > > > > Signed-off-by: Herve Codina > > Christophe Thanks for the review, Hervé -- Hervé Codina, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
[powerpc:merge] BUILD SUCCESS 55f63ce760d3914cff221c193f1032537af141f5
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git merge branch HEAD: 55f63ce760d3914cff221c193f1032537af141f5 Automatic merge of 'master' into merge (2023-01-09 11:31) elapsed time: 1518m configs tested: 60 configs skipped: 2 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: x86_64allnoconfig powerpc allnoconfig x86_64 defconfig x86_64 rhel-8.3-bpf x86_64 rhel-8.3-kunit m68k allmodconfig x86_64 rhel-8.3-kvm x86_64 rhel-8.3-syz arc allyesconfig x86_64 rhel-8.3 alphaallyesconfig m68k allyesconfig i386 randconfig-a001 i386 randconfig-a003 i386 randconfig-a005 x86_64 allyesconfig i386defconfig arc randconfig-r043-20230110 s390 randconfig-r044-20230110 x86_64randconfig-a013 riscvrandconfig-r042-20230110 x86_64randconfig-a011 arm defconfig x86_64randconfig-a002 x86_64randconfig-a015 x86_64randconfig-a006 x86_64randconfig-a004 arm64allyesconfig arm allyesconfig um i386_defconfig um x86_64_defconfig sh allmodconfig mips allyesconfig arc defconfig s390 allmodconfig alpha defconfig s390defconfig powerpc allmodconfig s390 allyesconfig i386 allyesconfig x86_64 rhel-8.3-func x86_64rhel-8.3-kselftests i386 randconfig-a014 i386 randconfig-a012 i386 randconfig-a016 ia64 allmodconfig clang tested configs: i386 randconfig-a002 i386 randconfig-a004 i386 randconfig-a006 hexagon randconfig-r041-20230110 arm randconfig-r046-20230110 x86_64randconfig-a014 hexagon randconfig-r045-20230110 x86_64randconfig-a012 x86_64randconfig-a005 x86_64randconfig-a001 x86_64randconfig-a016 x86_64randconfig-a003 i386 randconfig-a015 x86_64 rhel-8.3-rust -- 0-DAY CI Kernel Test Service https://01.org/lkp
Re: [PATCH v2 01/16] of: device: make of_device_uevent_modalias() take a const device *
On Wed, Jan 11, 2023 at 5:30 AM Greg Kroah-Hartman wrote: > > of_device_uevent_modalias() does not modify the device pointer passed to > it, so mark it constant. In order to properly do this, a number of > busses need to have a modalias function added as they were attempting to > just point to of_device_uevent_modalias instead of their bus-specific > modalias function. This is fine except if the prototype for a bus and > device type modalias function diverges and then problems could happen. To > prevent all of that, just wrap the call to of_device_uevent_modalias() > directly for each bus and device type individually. Why not just put the wrapper function in the DT code instead of making 4 copies of it? Rob
[PATCH v3 11/13] tty/serial: Call ->dtr_rts() parameter active consistently
Convert various parameter names for ->dtr_rts() and related functions
from onoff, on, and raise to active.
Reviewed-by: Jiri Slaby
Signed-off-by: Ilpo Järvinen
---
drivers/char/pcmcia/synclink_cs.c | 6 +++---
drivers/mmc/core/sdio_uart.c | 6 +++---
drivers/staging/greybus/uart.c| 4 ++--
drivers/tty/amiserial.c | 4 ++--
drivers/tty/hvc/hvc_console.h | 2 +-
drivers/tty/hvc/hvc_iucv.c| 6 +++---
drivers/tty/mxser.c | 4 ++--
drivers/tty/n_gsm.c | 4 ++--
drivers/tty/serial/serial_core.c | 8
drivers/tty/synclink_gt.c | 4 ++--
include/linux/tty_port.h | 4 ++--
include/linux/usb/serial.h| 2 +-
12 files changed, 27 insertions(+), 27 deletions(-)
diff --git a/drivers/char/pcmcia/synclink_cs.c
b/drivers/char/pcmcia/synclink_cs.c
index 46a0b586d234..1577eba6fe0e 100644
--- a/drivers/char/pcmcia/synclink_cs.c
+++ b/drivers/char/pcmcia/synclink_cs.c
@@ -378,7 +378,7 @@ static void async_mode(MGSLPC_INFO *info);
static void tx_timeout(struct timer_list *t);
static bool carrier_raised(struct tty_port *port);
-static void dtr_rts(struct tty_port *port, bool onoff);
+static void dtr_rts(struct tty_port *port, bool active);
#if SYNCLINK_GENERIC_HDLC
#define dev_to_port(D) (dev_to_hdlc(D)->priv)
@@ -2442,13 +2442,13 @@ static bool carrier_raised(struct tty_port *port)
return info->serial_signals & SerialSignal_DCD;
}
-static void dtr_rts(struct tty_port *port, bool onoff)
+static void dtr_rts(struct tty_port *port, bool active)
{
MGSLPC_INFO *info = container_of(port, MGSLPC_INFO, port);
unsigned long flags;
spin_lock_irqsave(>lock, flags);
- if (onoff)
+ if (active)
info->serial_signals |= SerialSignal_RTS | SerialSignal_DTR;
else
info->serial_signals &= ~(SerialSignal_RTS | SerialSignal_DTR);
diff --git a/drivers/mmc/core/sdio_uart.c b/drivers/mmc/core/sdio_uart.c
index c6b4b2b2a4b2..50536fe59f1a 100644
--- a/drivers/mmc/core/sdio_uart.c
+++ b/drivers/mmc/core/sdio_uart.c
@@ -542,20 +542,20 @@ static bool uart_carrier_raised(struct tty_port *tport)
/**
* uart_dtr_rts-port helper to set uart signals
* @tport: tty port to be updated
- * @onoff: set to turn on DTR/RTS
+ * @active: set to turn on DTR/RTS
*
* Called by the tty port helpers when the modem signals need to be
* adjusted during an open, close and hangup.
*/
-static void uart_dtr_rts(struct tty_port *tport, bool onoff)
+static void uart_dtr_rts(struct tty_port *tport, bool active)
{
struct sdio_uart_port *port =
container_of(tport, struct sdio_uart_port, port);
int ret = sdio_uart_claim_func(port);
if (ret)
return;
- if (!onoff)
+ if (!active)
sdio_uart_clear_mctrl(port, TIOCM_DTR | TIOCM_RTS);
else
sdio_uart_set_mctrl(port, TIOCM_DTR | TIOCM_RTS);
diff --git a/drivers/staging/greybus/uart.c b/drivers/staging/greybus/uart.c
index 92d49740d5a4..20a34599859f 100644
--- a/drivers/staging/greybus/uart.c
+++ b/drivers/staging/greybus/uart.c
@@ -701,7 +701,7 @@ static int gb_tty_ioctl(struct tty_struct *tty, unsigned
int cmd,
return -ENOIOCTLCMD;
}
-static void gb_tty_dtr_rts(struct tty_port *port, bool on)
+static void gb_tty_dtr_rts(struct tty_port *port, bool active)
{
struct gb_tty *gb_tty;
u8 newctrl;
@@ -709,7 +709,7 @@ static void gb_tty_dtr_rts(struct tty_port *port, bool on)
gb_tty = container_of(port, struct gb_tty, port);
newctrl = gb_tty->ctrlout;
- if (on)
+ if (active)
newctrl |= (GB_UART_CTRL_DTR | GB_UART_CTRL_RTS);
else
newctrl &= ~(GB_UART_CTRL_DTR | GB_UART_CTRL_RTS);
diff --git a/drivers/tty/amiserial.c b/drivers/tty/amiserial.c
index 29d4c554f6b8..d7515d61659e 100644
--- a/drivers/tty/amiserial.c
+++ b/drivers/tty/amiserial.c
@@ -1459,13 +1459,13 @@ static bool amiga_carrier_raised(struct tty_port *port)
return !(ciab.pra & SER_DCD);
}
-static void amiga_dtr_rts(struct tty_port *port, bool raise)
+static void amiga_dtr_rts(struct tty_port *port, bool active)
{
struct serial_state *info = container_of(port, struct serial_state,
tport);
unsigned long flags;
- if (raise)
+ if (active)
info->MCR |= SER_DTR|SER_RTS;
else
info->MCR &= ~(SER_DTR|SER_RTS);
diff --git a/drivers/tty/hvc/hvc_console.h b/drivers/tty/hvc/hvc_console.h
index 6d3428bf868f..9668f821db01 100644
--- a/drivers/tty/hvc/hvc_console.h
+++ b/drivers/tty/hvc/hvc_console.h
@@ -66,7 +66,7 @@ struct hv_ops {
int (*tiocmset)(struct hvc_struct *hp, unsigned int set, unsigned int
clear);
/* Callbacks to handle tty ports */
- void (*dtr_rts)(struct hvc_struct *hp, bool raise);
+ void
[PATCH v3 07/13] tty: Convert ->dtr_rts() to take bool argument
Convert the raise/on parameter in ->dtr_rts() to bool through the
callchain. The parameter is used like bool. In USB serial, there
remains a few implicit bool -> larger type conversions because some
devices use u8 in their control messages.
In moxa_tiocmget(), dtr variable was reused for line status which
requires int so use a separate variable for status.
Reviewed-by: Jiri Slaby
Signed-off-by: Ilpo Järvinen
---
drivers/char/pcmcia/synclink_cs.c| 4 +--
drivers/mmc/core/sdio_uart.c | 4 +--
drivers/staging/greybus/uart.c | 2 +-
drivers/tty/amiserial.c | 2 +-
drivers/tty/hvc/hvc_console.c| 4 +--
drivers/tty/hvc/hvc_console.h| 2 +-
drivers/tty/hvc/hvc_iucv.c | 4 +--
drivers/tty/moxa.c | 54 ++--
drivers/tty/mxser.c | 2 +-
drivers/tty/n_gsm.c | 2 +-
drivers/tty/serial/serial_core.c | 8 ++---
drivers/tty/synclink_gt.c| 2 +-
drivers/tty/tty_port.c | 4 +--
drivers/usb/class/cdc-acm.c | 2 +-
drivers/usb/serial/ch341.c | 2 +-
drivers/usb/serial/cp210x.c | 4 +--
drivers/usb/serial/cypress_m8.c | 6 ++--
drivers/usb/serial/digi_acceleport.c | 6 ++--
drivers/usb/serial/f81232.c | 2 +-
drivers/usb/serial/f81534.c | 2 +-
drivers/usb/serial/ftdi_sio.c| 2 +-
drivers/usb/serial/ipw.c | 2 +-
drivers/usb/serial/keyspan.c | 2 +-
drivers/usb/serial/keyspan_pda.c | 2 +-
drivers/usb/serial/mct_u232.c| 4 +--
drivers/usb/serial/mxuport.c | 2 +-
drivers/usb/serial/pl2303.c | 2 +-
drivers/usb/serial/quatech2.c| 2 +-
drivers/usb/serial/sierra.c | 2 +-
drivers/usb/serial/spcp8x5.c | 2 +-
drivers/usb/serial/ssu100.c | 2 +-
drivers/usb/serial/upd78f0730.c | 6 ++--
drivers/usb/serial/usb-serial.c | 2 +-
drivers/usb/serial/usb-wwan.h| 2 +-
drivers/usb/serial/usb_wwan.c| 2 +-
drivers/usb/serial/xr_serial.c | 6 ++--
include/linux/tty_port.h | 4 +--
include/linux/usb/serial.h | 2 +-
38 files changed, 84 insertions(+), 82 deletions(-)
diff --git a/drivers/char/pcmcia/synclink_cs.c
b/drivers/char/pcmcia/synclink_cs.c
index 4391138e1b8a..46a0b586d234 100644
--- a/drivers/char/pcmcia/synclink_cs.c
+++ b/drivers/char/pcmcia/synclink_cs.c
@@ -378,7 +378,7 @@ static void async_mode(MGSLPC_INFO *info);
static void tx_timeout(struct timer_list *t);
static bool carrier_raised(struct tty_port *port);
-static void dtr_rts(struct tty_port *port, int onoff);
+static void dtr_rts(struct tty_port *port, bool onoff);
#if SYNCLINK_GENERIC_HDLC
#define dev_to_port(D) (dev_to_hdlc(D)->priv)
@@ -2442,7 +2442,7 @@ static bool carrier_raised(struct tty_port *port)
return info->serial_signals & SerialSignal_DCD;
}
-static void dtr_rts(struct tty_port *port, int onoff)
+static void dtr_rts(struct tty_port *port, bool onoff)
{
MGSLPC_INFO *info = container_of(port, MGSLPC_INFO, port);
unsigned long flags;
diff --git a/drivers/mmc/core/sdio_uart.c b/drivers/mmc/core/sdio_uart.c
index 47f58258d8ff..c6b4b2b2a4b2 100644
--- a/drivers/mmc/core/sdio_uart.c
+++ b/drivers/mmc/core/sdio_uart.c
@@ -548,14 +548,14 @@ static bool uart_carrier_raised(struct tty_port *tport)
* adjusted during an open, close and hangup.
*/
-static void uart_dtr_rts(struct tty_port *tport, int onoff)
+static void uart_dtr_rts(struct tty_port *tport, bool onoff)
{
struct sdio_uart_port *port =
container_of(tport, struct sdio_uart_port, port);
int ret = sdio_uart_claim_func(port);
if (ret)
return;
- if (onoff == 0)
+ if (!onoff)
sdio_uart_clear_mctrl(port, TIOCM_DTR | TIOCM_RTS);
else
sdio_uart_set_mctrl(port, TIOCM_DTR | TIOCM_RTS);
diff --git a/drivers/staging/greybus/uart.c b/drivers/staging/greybus/uart.c
index 90ff07f2cbf7..92d49740d5a4 100644
--- a/drivers/staging/greybus/uart.c
+++ b/drivers/staging/greybus/uart.c
@@ -701,7 +701,7 @@ static int gb_tty_ioctl(struct tty_struct *tty, unsigned
int cmd,
return -ENOIOCTLCMD;
}
-static void gb_tty_dtr_rts(struct tty_port *port, int on)
+static void gb_tty_dtr_rts(struct tty_port *port, bool on)
{
struct gb_tty *gb_tty;
u8 newctrl;
diff --git a/drivers/tty/amiserial.c b/drivers/tty/amiserial.c
index 01c4fd3ce7c8..29d4c554f6b8 100644
--- a/drivers/tty/amiserial.c
+++ b/drivers/tty/amiserial.c
@@ -1459,7 +1459,7 @@ static bool amiga_carrier_raised(struct tty_port *port)
return !(ciab.pra & SER_DCD);
}
-static void amiga_dtr_rts(struct tty_port *port, int raise)
+static void amiga_dtr_rts(struct tty_port *port, bool raise)
{
struct serial_state *info = container_of(port, struct serial_state,
Re: [PATCH v2 06/10] soc: fsl: qe: Add support for QMC
Le 06/01/2023 à 17:37, Herve Codina a écrit :
> The QMC (QUICC Multichannel Controller) is available on some
> PowerQUICC SoC such as the MPC885 or MPC866.
Same, that's QMC for CPM for the time being, should that be made clear
in the subject ?
QE also has QMC and this driver might be used for QE QMC as well with
some enhancement, maybe that could be explained here ?
I see you are using in_be16(), out_be16() etc
That's specific to powerpc arch, maybe it is better to use ioread16be,
iowrite16be() etc
See commit 3f39f38ea91d ("soc: fsl: qe: replace qe_io{read,write}*
wrappers by generic io{read,write}*") and commit 6ac9b61786cc ("soc:
fsl: qe: introduce qe_io{read,write}* wrappers") for information.
>
> It emulates up to 64 channels within one serial controller
> using the same TDM physical interface routed from the TSA.
>
> Signed-off-by: Herve Codina
In some places, you comments use the network style, not the generic style.
Christophe
Re: [PATCH v2 02/10] soc: fsl: qe: Add support for TSA
Le 06/01/2023 à 17:37, Herve Codina a écrit : > The TSA (Time Slot Assigner) is available in some > PowerQUICC SoC such as the MPC885 or MPC866. > > Its purpose is to route some TDM time-slots to other > internal serial controllers. Is the subject correct ? As far as I understand this patch adds support for the TSA on the CPM (exactly on CPM1), not on the QE. By the way, there are already some embryo for handling TSA on QE in drivers/soc/fsl/qe/qe-tdm.c > > Signed-off-by: Herve Codina Christophe
Re: [PATCH 2/2] powerpc/64s/radix: Fix RWX mapping with relocated kernel
> On 10-Jan-2023, at 6:17 PM, Michael Ellerman wrote:
>
> If a relocatable kernel is loaded at a non-zero address and told not to
> relocate to zero (kdump or RELOCATABLE_TEST), the mapping of the
> interrupt code at zero is left with RWX permissions.
>
> That is a security weakness, and leads to a warning at boot if
> CONFIG_DEBUG_WX is enabled:
>
> powerpc/mm: Found insecure W+X mapping at address
> 056435bc/0xc000
> WARNING: CPU: 1 PID: 1 at arch/powerpc/mm/ptdump/ptdump.c:193
> note_page+0x484/0x4c0
> CPU: 1 PID: 1 Comm: swapper/0 Not tainted
> 6.2.0-rc1-1-g8ae8e98aea82-dirty #175
> Hardware name: IBM pSeries (emulated by qemu) POWER9 (raw) 0x4e1202
> 0xf05 of:SLOF,git-dd0dca hv:linux,kvm pSeries
> NIP: c04a1c34 LR: c04a1c30 CTR:
> REGS: c3503770 TRAP: 0700 Not tainted
> (6.2.0-rc1-1-g8ae8e98aea82-dirty)
> MSR: 82029033 CR: 24000220 XER:
>
> CFAR: c0545a58 IRQMASK: 0
> ...
> NIP note_page+0x484/0x4c0
> LR note_page+0x480/0x4c0
> Call Trace:
>note_page+0x480/0x4c0 (unreliable)
>ptdump_pmd_entry+0xc8/0x100
>walk_pgd_range+0x618/0xab0
>walk_page_range_novma+0x74/0xc0
>ptdump_walk_pgd+0x98/0x170
>ptdump_check_wx+0x94/0x100
>mark_rodata_ro+0x30/0x70
>kernel_init+0x78/0x1a0
>ret_from_kernel_thread+0x5c/0x64
>
> The fix has two parts. Firstly the pages from zero up to the end of
> interrupts need to be marked read-only, so that they are left with R-X
> permissions. Secondly the mapping logic needs to be taught to ensure
> there is a page boundary at the end of the interrupt region, so that the
> permission change only applies to the interrupt text, and not the region
> following it.
>
> Fixes: c55d7b5e6426 ("powerpc: Remove STRICT_KERNEL_RWX incompatibility with
> RELOCATABLE")
> Signed-off-by: Michael Ellerman
> ---
Thanks Michael. This fixes the problem reported earlier
https://lore.kernel.org/linuxppc-dev/48206911-fd3d-401a-a69d-1a79403e7...@linux.ibm.com/
Reported-by: Sachin Sant
Tested-by: Sachin Sant
- Sachin
[PATCH v2 08/16] vio: move to_vio_dev() to use container_of_const()
The driver core is changing to pass some pointers as const, so move
to_vio_dev() to use container_of_const() to handle this change.
to_vio_dev() now properly keeps the const-ness of the pointer passed
into it, while as before it could be lost.
Cc: Michael Ellerman
Cc: Nicholas Piggin
Cc: Christophe Leroy
Cc: "David S. Miller"
Cc: "Gustavo A. R. Silva"
Cc: Kees Cook
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-ker...@vger.kernel.org
Cc: sparcli...@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman
---
arch/powerpc/include/asm/vio.h | 5 +
arch/sparc/include/asm/vio.h | 5 +
2 files changed, 2 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/include/asm/vio.h b/arch/powerpc/include/asm/vio.h
index e7479a4abf96..cc9b787627ad 100644
--- a/arch/powerpc/include/asm/vio.h
+++ b/arch/powerpc/include/asm/vio.h
@@ -161,10 +161,7 @@ static inline struct vio_driver *to_vio_driver(struct
device_driver *drv)
return container_of(drv, struct vio_driver, driver);
}
-static inline struct vio_dev *to_vio_dev(struct device *dev)
-{
- return container_of(dev, struct vio_dev, dev);
-}
+#define to_vio_dev(__dev) container_of_const(__dev, struct vio_dev, dev)
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_VIO_H */
diff --git a/arch/sparc/include/asm/vio.h b/arch/sparc/include/asm/vio.h
index 2d7bdf665fd3..8a0c3c11c9ce 100644
--- a/arch/sparc/include/asm/vio.h
+++ b/arch/sparc/include/asm/vio.h
@@ -488,10 +488,7 @@ static inline struct vio_driver *to_vio_driver(struct
device_driver *drv)
return container_of(drv, struct vio_driver, driver);
}
-static inline struct vio_dev *to_vio_dev(struct device *dev)
-{
- return container_of(dev, struct vio_dev, dev);
-}
+#define to_vio_dev(__dev) container_of_const(__dev, struct vio_dev, dev)
int vio_ldc_send(struct vio_driver_state *vio, void *data, int len);
void vio_link_state_change(struct vio_driver_state *vio, int event);
--
2.39.0
[PATCH v2 01/16] of: device: make of_device_uevent_modalias() take a const device *
of_device_uevent_modalias() does not modify the device pointer passed to
it, so mark it constant. In order to properly do this, a number of
busses need to have a modalias function added as they were attempting to
just point to of_device_uevent_modalias instead of their bus-specific
modalias function. This is fine except if the prototype for a bus and
device type modalias function diverges and then problems could happen. To
prevent all of that, just wrap the call to of_device_uevent_modalias()
directly for each bus and device type individually.
Cc: Michael Ellerman
Cc: Nicholas Piggin
Cc: Christophe Leroy
Cc: Chen-Yu Tsai
Cc: Jernej Skrabec
Cc: Samuel Holland
Cc: David Airlie
Cc: Daniel Vetter
Cc: Benjamin Herrenschmidt
Cc: Rob Herring
Cc: Frank Rowand
Cc: Liang He
Cc: Greg Kroah-Hartman
Cc: Thomas Gleixner
Cc: Christophe JAILLET
Cc: Thomas Zimmermann
Cc: Dmitry Baryshkov
Cc: Douglas Anderson
Cc: Lyude Paul
Cc: Corentin Labbe
Cc: Zou Wei
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-su...@lists.linux.dev
Cc: dri-de...@lists.freedesktop.org
Cc: devicet...@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman
---
arch/powerpc/platforms/pseries/ibmebus.c | 7 ++-
drivers/bus/sunxi-rsb.c | 7 ++-
drivers/gpu/drm/display/drm_dp_aux_bus.c | 7 ++-
drivers/macintosh/macio_asic.c | 7 ++-
drivers/of/device.c | 4 ++--
include/linux/of_device.h| 4 ++--
6 files changed, 28 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/ibmebus.c
b/arch/powerpc/platforms/pseries/ibmebus.c
index a870cada7acd..58b798a0e879 100644
--- a/arch/powerpc/platforms/pseries/ibmebus.c
+++ b/arch/powerpc/platforms/pseries/ibmebus.c
@@ -426,9 +426,14 @@ static struct attribute *ibmebus_bus_device_attrs[] = {
};
ATTRIBUTE_GROUPS(ibmebus_bus_device);
+static int ibmebus_bus_modalias(struct device *dev, struct kobj_uevent_env
*env)
+{
+ return of_device_uevent_modalias(dev, env);
+}
+
struct bus_type ibmebus_bus_type = {
.name = "ibmebus",
- .uevent= of_device_uevent_modalias,
+ .uevent= ibmebus_bus_modalias,
.bus_groups = ibmbus_bus_groups,
.match = ibmebus_bus_bus_match,
.probe = ibmebus_bus_device_probe,
diff --git a/drivers/bus/sunxi-rsb.c b/drivers/bus/sunxi-rsb.c
index 3aa91aed3bf7..a180af11e034 100644
--- a/drivers/bus/sunxi-rsb.c
+++ b/drivers/bus/sunxi-rsb.c
@@ -172,12 +172,17 @@ static void sunxi_rsb_device_remove(struct device *dev)
drv->remove(to_sunxi_rsb_device(dev));
}
+static int sunxi_rsb_device_modalias(struct device *dev, struct
kobj_uevent_env *env)
+{
+ return of_device_uevent_modalias(dev, env);
+}
+
static struct bus_type sunxi_rsb_bus = {
.name = RSB_CTRL_NAME,
.match = sunxi_rsb_device_match,
.probe = sunxi_rsb_device_probe,
.remove = sunxi_rsb_device_remove,
- .uevent = of_device_uevent_modalias,
+ .uevent = sunxi_rsb_device_modalias,
};
static void sunxi_rsb_dev_release(struct device *dev)
diff --git a/drivers/gpu/drm/display/drm_dp_aux_bus.c
b/drivers/gpu/drm/display/drm_dp_aux_bus.c
index f5741b45ca07..e31a0261c53e 100644
--- a/drivers/gpu/drm/display/drm_dp_aux_bus.c
+++ b/drivers/gpu/drm/display/drm_dp_aux_bus.c
@@ -161,9 +161,14 @@ static void dp_aux_ep_dev_release(struct device *dev)
kfree(aux_ep_with_data);
}
+static int dp_aux_ep_dev_modalias(struct device *dev, struct kobj_uevent_env
*env)
+{
+ return of_device_uevent_modalias(dev, env);
+}
+
static struct device_type dp_aux_device_type_type = {
.groups = dp_aux_ep_dev_groups,
- .uevent = of_device_uevent_modalias,
+ .uevent = dp_aux_ep_dev_modalias,
.release= dp_aux_ep_dev_release,
};
diff --git a/drivers/macintosh/macio_asic.c b/drivers/macintosh/macio_asic.c
index 3bc1f374e657..7f2b0107c733 100644
--- a/drivers/macintosh/macio_asic.c
+++ b/drivers/macintosh/macio_asic.c
@@ -128,12 +128,17 @@ static int macio_device_resume(struct device * dev)
return 0;
}
+static int macio_device_modalias(struct device *dev, struct kobj_uevent_env
*env)
+{
+ return of_device_uevent_modalias(dev, env);
+}
+
extern const struct attribute_group *macio_dev_groups[];
struct bus_type macio_bus_type = {
.name = "macio",
.match = macio_bus_match,
- .uevent = of_device_uevent_modalias,
+ .uevent = macio_device_modalias,
.probe = macio_device_probe,
.remove = macio_device_remove,
.shutdown = macio_device_shutdown,
diff --git a/drivers/of/device.c b/drivers/of/device.c
index c674a13c3055..dda51b7ce597 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -248,7 +248,7 @@ const void *of_device_get_match_data(const struct device
RE: [PATCH 08/41] mm: introduce CONFIG_PER_VMA_LOCK
From: Ingo Molnar > Sent: 11 January 2023 09:54 > > * Michal Hocko wrote: > > > On Tue 10-01-23 16:44:42, Suren Baghdasaryan wrote: > > > On Tue, Jan 10, 2023 at 4:39 PM Davidlohr Bueso wrote: > > > > > > > > On Mon, 09 Jan 2023, Suren Baghdasaryan wrote: > > > > > > > > >This configuration variable will be used to build the support for VMA > > > > >locking during page fault handling. > > > > > > > > > >This is enabled by default on supported architectures with SMP and MMU > > > > >set. > > > > > > > > > >The architecture support is needed since the page fault handler is > > > > >called > > > > >from the architecture's page faulting code which needs modifications to > > > > >handle faults under VMA lock. > > > > > > > > I don't think that per-vma locking should be something that is > > > > user-configurable. > > > > It should just be depdendant on the arch. So maybe just remove > > > > CONFIG_PER_VMA_LOCK? > > > > > > Thanks for the suggestion! I would be happy to make that change if > > > there are no objections. I think the only pushback might have been the > > > vma size increase but with the latest optimization in the last patch > > > maybe that's less of an issue? > > > > Has vma size ever been a real problem? Sure there might be a lot of those > > but your patch increases it by rwsem (without the last patch) which is > > something like 40B on top of 136B vma so we are talking about 400B in > > total which even with wild mapcount limits shouldn't really be > > prohibitive. With a default map count limit we are talking about 2M > > increase at most (per address space). > > > > Or are you aware of any specific usecases where vma size is a real > > problem? > > 40 bytes for the rwsem, plus the patch also adds a 32-bit sequence counter: > > + int vm_lock_seq; > + struct rw_semaphore lock; > > So it's +44 bytes. Depend in whether vm_lock_seq goes into a padding hole or not it will be 40 or 48 bytes. But if these structures are allocated individually (not an array) then it depends on how may items kmalloc() fits into a page (or 2,4). David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
Re: [PATCH v2 08/10] dt-bindings: sound: Add support for QMC audio
On 10/01/2023 09:07, Herve Codina wrote: >>> + qmc-chan: >> >> Missing vendor prefix. > > Will be changed to 'fsl,qmc-chan' > >> >>> +$ref: /schemas/types.yaml#/definitions/phandle-array >> >> Why this is not a phandle? > > I have try '$ref: /schemas/types.yaml#/definitions/phandle' > > I have an error from make dt_binding_check: > dai@16:fsl,qmc-chan:0: [4294967295, 16] is too long > > I need a phandle with an argument ie < 16>. > Is there an alternative to phandle-array to handle this case ? OK, then you need items like here: https://elixir.bootlin.com/linux/v5.18-rc1/source/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml#L42 Best regards, Krzysztof
Re: [PATCH v2 01/10] dt-bindings: soc: fsl: cpm_qe: Add TSA controller
On 10/01/2023 09:04, Herve Codina wrote: > Hi Krzysztof, > > On Sun, 8 Jan 2023 16:10:38 +0100 > Krzysztof Kozlowski wrote: > > [...] > >>> + '#size-cells': >>> +const: 0 >>> + >>> +patternProperties: >>> + "^tdm@[0-1]$": >> >> Use consistent quotes - either ' or " > > Ok, I will change on v3. > I will also change them on the other bindings present in the > series. > >> >>> +description: >>> + The TDM managed by this controller >>> +type: object >>> + >>> +properties: >>> + reg: >>> +minimum: 0 >>> +maximum: 1 >>> +description: >>> + The TDM number for this TDM, 0 for TDMa and 1 for TDMb >>> + >>> + fsl,common-rxtx-pins: >>> +$ref: /schemas/types.yaml#/definitions/flag >>> +description: >>> + Use common pins for both transmit and receive >> >> What are the "common" pins? Without this property device is using >> uncommon pins? This does not make sense... > > Common in the "shared" sense. > The hardware can use dedicated pins for Tx clock, Tx sync, > Rx clock and Rx sync or use only 2 pins, Tx/Rx clock and > Rx/Rx sync. > > Without the property, we use the 4 pins and with the property, > we use 2 pins. Just use this as description. > >> >>> + >>> + clocks: true >>> + clock-names: true >> >> Both need constraints. > > The constraints are present later in the file as the number > of clocks depends on the 'fsl,common-rxtx-pins' property. OK, but still top level properties need widest constraints. > > I will remove these two lines in the v3 series as they are > not needed. 'clocks' and 'clock-names' are handled in the > conditional part. No, top level properties must contain them. > >> > [...] >>> + >>> + fsl,rx-frame-sync-delay: >>> +$ref: /schemas/types.yaml#/definitions/uint32 >>> +enum: [0, 1, 2, 3] >>> +default: 0 >>> +description: | >>> + Receive frame sync delay. >> >> Delay in what units? > > The unit is a number of bits. > I will rename to fsl,rx-frame-sync-delay-bits and change the description > to 'Receive frame sync delay in number of bits' > > I will do also the same for fsl,tx-frame-sync-delay property. OK > >> >>> + Indicates the delay between the Rx sync and the first bit of the >>> + Rx frame. 0 for no bit delay. 1, 2 or 3 for 1, 2 or 3 bits delay. >>> + >>> + fsl,tx-frame-sync-delay: >>> +$ref: /schemas/types.yaml#/definitions/uint32 >>> +enum: [0, 1, 2, 3] >>> +default: 0 >>> +description: | >>> + Transmit frame sync delay. >>> + Indicates the delay between the Tx sync and the first bit of the >>> + Tx frame. 0 for no bit delay. 1, 2 or 3 for 1, 2 or 3 bits delay. >>> + >>> + fsl,clock-falling-edge: >>> +$ref: /schemas/types.yaml#/definitions/flag >>> +description: | >>> + Data is sent on falling edge of the clock (and received on the >>> + rising edge). >>> + If 'clock-falling-edge' is not present, data is sent on the >>> + rising edge (and received on the falling edge). >>> + >>> + fsl,fsync-rising-edge: >>> +$ref: /schemas/types.yaml#/definitions/flag >>> +description: >>> + Frame sync pulses are sampled with the rising edge of the channel >>> + clock. If 'fsync-rising-edge' is not present, pulses are sample >>> + with e falling edge. >>> + >>> + fsl,double-speed-clock: >>> +$ref: /schemas/types.yaml#/definitions/flag >>> +description: >>> + The channel clock is twice the data rate. >>> + >>> + fsl,grant-mode: >>> +$ref: /schemas/types.yaml#/definitions/flag >>> +description: >>> + Grant mode enabled. >> >> This we know from property name. You need to describe what it is and >> what it does. > > Instead of describing it, I will simply remove the property (I should > have done already). > I cannot test the 'grant mode' enabled with my hardware and so > I prefer keeping it disabled. > This property, if needed, could be add later setting it optional > with default to 'disabled'. > >> >>> + >>> + tx_ts_routes: >> >> No underscores, missing vendor prefix. > > Indeed, will be change to fsl,tx-ts-routes (idem for rx_ts_routes). > >> >>> +$ref: /schemas/types.yaml#/definitions/uint32-matrix >>> +description: | >>> + A list of tupple that indicates the Tx time-slots routes. >>> +tx_ts_routes = >>> + < 2 0 0>, /* The first 2 time slots are not used */ >>> + < 3 1 0>, /* The next 3 ones are route to SCC2 */ >>> + < 4 0 0>, /* The next 4 ones are not used */ >>> + < 2 2 0>; /* The nest 2 ones are route to SCC3 */ >>> +items: >>> + items: >>> +- description: >>> +The number of time-slots >>> + minimum: 1 >>> +
Re: [PATCH 08/41] mm: introduce CONFIG_PER_VMA_LOCK
* Michal Hocko wrote: > On Tue 10-01-23 16:44:42, Suren Baghdasaryan wrote: > > On Tue, Jan 10, 2023 at 4:39 PM Davidlohr Bueso wrote: > > > > > > On Mon, 09 Jan 2023, Suren Baghdasaryan wrote: > > > > > > >This configuration variable will be used to build the support for VMA > > > >locking during page fault handling. > > > > > > > >This is enabled by default on supported architectures with SMP and MMU > > > >set. > > > > > > > >The architecture support is needed since the page fault handler is called > > > >from the architecture's page faulting code which needs modifications to > > > >handle faults under VMA lock. > > > > > > I don't think that per-vma locking should be something that is > > > user-configurable. > > > It should just be depdendant on the arch. So maybe just remove > > > CONFIG_PER_VMA_LOCK? > > > > Thanks for the suggestion! I would be happy to make that change if > > there are no objections. I think the only pushback might have been the > > vma size increase but with the latest optimization in the last patch > > maybe that's less of an issue? > > Has vma size ever been a real problem? Sure there might be a lot of those > but your patch increases it by rwsem (without the last patch) which is > something like 40B on top of 136B vma so we are talking about 400B in > total which even with wild mapcount limits shouldn't really be > prohibitive. With a default map count limit we are talking about 2M > increase at most (per address space). > > Or are you aware of any specific usecases where vma size is a real > problem? 40 bytes for the rwsem, plus the patch also adds a 32-bit sequence counter: + int vm_lock_seq; + struct rw_semaphore lock; So it's +44 bytes. Thanks, Ingo
[PATCH v3] net: wan: Add checks for NULL for utdm in undo_uhdlc_init and unmap_si_regs
If uhdlc_priv_tsa != 1 then utdm is not initialized. And if ret != NULL then goto undo_uhdlc_init, where utdm is dereferenced. Same if dev == NULL. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Esina Ekaterina --- v3: Remove braces v2: Add check for NULL for unmap_si_regs --- drivers/net/wan/fsl_ucc_hdlc.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/net/wan/fsl_ucc_hdlc.c b/drivers/net/wan/fsl_ucc_hdlc.c index 22edea6ca4b8..8166708c7190 100644 --- a/drivers/net/wan/fsl_ucc_hdlc.c +++ b/drivers/net/wan/fsl_ucc_hdlc.c @@ -1243,9 +1243,11 @@ static int ucc_hdlc_probe(struct platform_device *pdev) free_dev: free_netdev(dev); undo_uhdlc_init: - iounmap(utdm->siram); + if (utdm != NULL) + iounmap(utdm->siram); unmap_si_regs: - iounmap(utdm->si_regs); + if (utdm != NULL) + iounmap(utdm->si_regs); free_utdm: if (uhdlc_priv->tsa) kfree(utdm); -- 2.39.0
Re: [PATCH 08/41] mm: introduce CONFIG_PER_VMA_LOCK
On Tue 10-01-23 16:44:42, Suren Baghdasaryan wrote: > On Tue, Jan 10, 2023 at 4:39 PM Davidlohr Bueso wrote: > > > > On Mon, 09 Jan 2023, Suren Baghdasaryan wrote: > > > > >This configuration variable will be used to build the support for VMA > > >locking during page fault handling. > > > > > >This is enabled by default on supported architectures with SMP and MMU > > >set. > > > > > >The architecture support is needed since the page fault handler is called > > >from the architecture's page faulting code which needs modifications to > > >handle faults under VMA lock. > > > > I don't think that per-vma locking should be something that is > > user-configurable. > > It should just be depdendant on the arch. So maybe just remove > > CONFIG_PER_VMA_LOCK? > > Thanks for the suggestion! I would be happy to make that change if > there are no objections. I think the only pushback might have been the > vma size increase but with the latest optimization in the last patch > maybe that's less of an issue? Has vma size ever been a real problem? Sure there might be a lot of those but your patch increases it by rwsem (without the last patch) which is something like 40B on top of 136B vma so we are talking about 400B in total which even with wild mapcount limits shouldn't really be prohibitive. With a default map count limit we are talking about 2M increase at most (per address space). Or are you aware of any specific usecases where vma size is a real problem? -- Michal Hocko SUSE Labs
Re: [PATCH 2/4] dt-bindings: usb: Convert multiple "usb-ohci" bindings to DT schema
Hi Rob, I love your patch! Perhaps something to improve: [auto build test WARNING on 1b929c02afd37871d5afb9d498426f83432e71c2] url: https://github.com/intel-lab-lkp/linux/commits/Rob-Herring/dt-bindings-usb-Remove-obsolete-brcm-bcm3384-usb-txt/20230111-072007 base: 1b929c02afd37871d5afb9d498426f83432e71c2 patch link: https://lore.kernel.org/r/20230110-dt-usb-v1-2-8e366e326513%40kernel.org patch subject: [PATCH 2/4] dt-bindings: usb: Convert multiple "usb-ohci" bindings to DT schema reproduce: # https://github.com/intel-lab-lkp/linux/commit/ba91c0f61e446a9bc5008e2cc562727f6300da4e git remote add linux-review https://github.com/intel-lab-lkp/linux git fetch --no-tags linux-review Rob-Herring/dt-bindings-usb-Remove-obsolete-brcm-bcm3384-usb-txt/20230111-072007 git checkout ba91c0f61e446a9bc5008e2cc562727f6300da4e make menuconfig # enable CONFIG_COMPILE_TEST, CONFIG_WARN_MISSING_DOCUMENTS, CONFIG_WARN_ABI_ERRORS make htmldocs If you fix the issue, kindly add following tag where applicable | Reported-by: kernel test robot All warnings (new ones prefixed by >>): >> Warning: Documentation/devicetree/bindings/mfd/omap-usb-host.txt references >> a file that doesn't exist: >> Documentation/devicetree/bindings/usb/ohci-omap3.txt -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests # # Automatically generated file; DO NOT EDIT. # Linux/x86_64 6.2.0-rc1 Kernel Configuration # CONFIG_CC_VERSION_TEXT="gcc-11 (Debian 11.3.0-8) 11.3.0" CONFIG_CC_IS_GCC=y CONFIG_GCC_VERSION=110300 CONFIG_CLANG_VERSION=0 CONFIG_AS_IS_GNU=y CONFIG_AS_VERSION=23990 CONFIG_LD_IS_BFD=y CONFIG_LD_VERSION=23990 CONFIG_LLD_VERSION=0 CONFIG_CC_CAN_LINK=y CONFIG_CC_CAN_LINK_STATIC=y CONFIG_CC_HAS_ASM_GOTO_OUTPUT=y CONFIG_CC_HAS_ASM_GOTO_TIED_OUTPUT=y CONFIG_CC_HAS_ASM_INLINE=y CONFIG_CC_HAS_NO_PROFILE_FN_ATTR=y CONFIG_PAHOLE_VERSION=123 CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_TABLE_SORT=y CONFIG_THREAD_INFO_IN_TASK=y # # General setup # CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_COMPILE_TEST=y # CONFIG_WERROR is not set CONFIG_LOCALVERSION="" CONFIG_BUILD_SALT="" CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_HAVE_KERNEL_LZ4=y CONFIG_HAVE_KERNEL_ZSTD=y CONFIG_KERNEL_GZIP=y # CONFIG_KERNEL_BZIP2 is not set # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set # CONFIG_KERNEL_LZ4 is not set # CONFIG_KERNEL_ZSTD is not set CONFIG_DEFAULT_INIT="" CONFIG_DEFAULT_HOSTNAME="(none)" # CONFIG_SYSVIPC is not set # CONFIG_WATCH_QUEUE is not set # CONFIG_CROSS_MEMORY_ATTACH is not set # CONFIG_USELIB is not set CONFIG_HAVE_ARCH_AUDITSYSCALL=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_HARDIRQS_SW_RESEND=y CONFIG_IRQ_DOMAIN=y CONFIG_IRQ_DOMAIN_HIERARCHY=y CONFIG_GENERIC_IRQ_MATRIX_ALLOCATOR=y CONFIG_GENERIC_IRQ_RESERVATION_MODE=y CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y # end of IRQ subsystem CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_ARCH_CLOCKSOURCE_INIT=y CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_HAVE_POSIX_CPU_TIMERS_TASK_WORK=y CONFIG_POSIX_CPU_TIMERS_TASK_WORK=y # # Timers subsystem # CONFIG_HZ_PERIODIC=y # CONFIG_NO_HZ_IDLE is not set # CONFIG_NO_HZ is not set # CONFIG_HIGH_RES_TIMERS is not set CONFIG_CLOCKSOURCE_WATCHDOG_MAX_SKEW_US=100 # end of Timers subsystem CONFIG_HAVE_EBPF_JIT=y CONFIG_ARCH_WANT_DEFAULT_BPF_JIT=y # # BPF subsystem # # CONFIG_BPF_SYSCALL is not set # end of BPF subsystem CONFIG_PREEMPT_NONE_BUILD=y CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set # CONFIG_PREEMPT_DYNAMIC is not set # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set # CONFIG_IRQ_TIME_ACCOUNTING is not set # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_PSI is not set # end of CPU/Task time and stats accounting CONFIG_CPU_ISOLATION=y # # RCU Subsystem # CONFIG_TINY_RCU=y # CONFIG_RCU_EXPERT is not set CONFIG_SRCU=y CONFIG_TINY_SRCU=y # end of RCU Subsystem # CONFIG_IKCONFIG is not set # CONFIG_IKHEADERS is not set CONFIG_LOG_BUF_SHIFT=17 CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT=13 CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y # # Scheduler features # # end of Scheduler features CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH=y CONFIG_CC_HAS_INT128=y CONFIG_CC_IMPLICIT_FALLTHROUGH="-Wimplicit-fallthrough=5" CONFIG_GCC12_NO_ARRAY_BOUNDS=y CONFIG_ARCH_SUPPORTS_INT128=y # CONFIG_CGROUPS is not set CONFIG_NAMESPACES=y # CONFIG_UTS_NS is not set # CONFIG_TIME_NS is not set # CONFIG_USER_NS is not set # CONFI
