Re: [PATCH net] eth: fealnx: bring back this old driver
Hello: This patch was applied to netdev/net.git (main) by Jakub Kicinski : On Tue, 7 Mar 2023 09:19:30 -0800 you wrote: > This reverts commit d5e2d038dbece821f1af57acbeded3aa9a1832c1. > > We have a report of this chip being used on a > > SURECOM EP-320X-S 100/10M Ethernet PCI Adapter > > which could still have been purchased in some parts > of the world 3 years ago. > > [...] Here is the summary with links: - [net] eth: fealnx: bring back this old driver https://git.kernel.org/netdev/net/c/8f1482080104 You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html
Re: [PATCH v4 1/2] powerpc/mm: Support execute-only memory on the Radix MMU
On Wed, 2023-03-08 at 16:27 +0100, Michal Suchánek wrote: > Hello, > > On Wed, Aug 31, 2022 at 11:13:59PM +1000, Michael Ellerman wrote: > > On Wed, 17 Aug 2022 15:06:39 +1000, Russell Currey wrote: > > > Add support for execute-only memory (XOM) for the Radix MMU by > > > using an > > > execute-only mapping, as opposed to the RX mapping used by > > > powerpc's > > > other MMUs. > > > > > > The Hash MMU already supports XOM through the execute-only pkey, > > > which is a separate mechanism shared with x86. A PROT_EXEC-only > > > mapping > > > will map to RX, and then the pkey will be applied on top of it. > > > > > > [...] > > > > Applied to powerpc/next. > > > > [1/2] powerpc/mm: Support execute-only memory on the Radix MMU > > > > https://git.kernel.org/powerpc/c/395cac7752b905318ae454a8b859d4c190485510 > > This breaks libaio tests (on POWER9 hash PowerVM): > https://pagure.io/libaio/blob/master/f/harness/cases/5.t#_43 > > cases/5.p > expect 512: (w), res = 512 [Success] > expect 512: (r), res = 512 [Success] > expect 512: (r), res = 512 [Success] > expect 512: (w), res = 512 [Success] > expect 512: (w), res = 512 [Success] > expect -14: (r), res = -14 [Bad address] > expect 512: (r), res = 512 [Success] > expect 512: (w), res = 512 [Success] > test cases/5.t completed PASSED. > > cases/5.p > expect 512: (w), res = 512 [Success] > expect 512: (r), res = 512 [Success] > expect 512: (r), res = 512 [Success] > expect 512: (w), res = 512 [Success] > expect 512: (w), res = 512 [Success] > expect -14: (r), res = -14 [Bad address] > expect 512: (r), res = 512 [Success] > expect -14: (w), res = 512 [Success] -- FAILED > test cases/5.t completed FAILED. > > Can you have a look if that test assumption is OK? Hi Michal, thanks for the report. This wasn't an intended behaviour change, so it is a bug. I have no idea why we hit the fault in write() but not in io_submit(), though. The same issue applies under Radix. What's happening here is that we're taking a page fault and calling into access_error() and returning true when we shouldn't. Previously we didn't check for read faults and only checked for PROT_NONE. My patch checks the vma flags to see if they lack VM_READ after we check for exec and write, which ignores that VM_WRITE implies read This means we're mishandling faults for write-only mappings by assuming that the lack of VM_READ means we're faulting from read, when that should only be possible under a PROT_EXEC-only mapping. I think the correct behaviour is if (unlikely(!(vma->vm_flags & (VM_READ | VM_WRITE in access_error(). Will do some more testing and send a patch soon. I also need to verify that write implying read is true for all powerpc platforms. - Russell > > Thanks > > Michal
Re: [PATCH v2] vdso: Improve cmd_vdso_check to check all dynamic relocations
On Fri, Jan 27, 2023 at 3:19 PM Fangrui Song wrote: > On Thu, Dec 29, 2022 at 11:22 AM Palmer Dabbelt > wrote: > > > > On Wed, 21 Dec 2022 15:51:47 PST (-0800), mask...@google.com wrote: > > > The actual intention is that no dynamic relocation exists. However, > some > > > GNU ld ports produce unneeded R_*_NONE. (If a port fails to determine > > > the exact .rel[a].dyn size, the trailing zeros become R_*_NONE > > > relocations. E.g. ld's powerpc port recently fixed > > > https://sourceware.org/bugzilla/show_bug.cgi?id=29540) R_*_NONE are > > > generally no-op in the dynamic loaders. So just ignore them. > > > > > > With the change, we can remove ARCH_REL_TYPE_ABS. ARCH_REL_TYPE_ABS is > a > > > bit misnomer as ports may check RELAVETIVE/GLOB_DAT/JUMP_SLOT which are > > > not called "absolute relocations". (The patch is motivated by the arm64 > > > port missing R_AARCH64_RELATIVE.) > > > > > > Signed-off-by: Fangrui Song > > > Reviewed-by: Christophe Leroy > > > --- > > > Change from v1: > > > * rebase after 8ac3b5cd3e0521d92f9755e90d140382fc292510 (lib/vdso: use > "grep -E" instead of "egrep") > > > * change the commit message to mention an example GNU ld bug; no > longer say the patch fixes a deprecated egrep use > > > --- > > > arch/arm/vdso/Makefile| 3 --- > > > arch/arm64/kernel/vdso/Makefile | 3 --- > > > arch/arm64/kernel/vdso32/Makefile | 3 --- > > > arch/csky/kernel/vdso/Makefile| 3 --- > > > arch/loongarch/vdso/Makefile | 3 --- > > > arch/mips/vdso/Makefile | 3 --- > > > arch/powerpc/kernel/vdso/Makefile | 1 - > > > arch/riscv/kernel/vdso/Makefile | 3 --- > > > arch/s390/kernel/vdso32/Makefile | 2 -- > > > arch/s390/kernel/vdso64/Makefile | 2 -- > > > arch/x86/entry/vdso/Makefile | 4 > > > lib/vdso/Makefile | 13 - > > > 12 files changed, 4 insertions(+), 39 deletions(-) > > > > [snip] > > > > > diff --git a/arch/riscv/kernel/vdso/Makefile > b/arch/riscv/kernel/vdso/Makefile > > > index 06e6b27f3bcc..d85c37e11b21 100644 > > > --- a/arch/riscv/kernel/vdso/Makefile > > > +++ b/arch/riscv/kernel/vdso/Makefile > > > @@ -1,9 +1,6 @@ > > > # SPDX-License-Identifier: GPL-2.0-only > > > # Copied from arch/tile/kernel/vdso/Makefile > > > > > > -# Absolute relocation type $(ARCH_REL_TYPE_ABS) needs to be defined > before > > > -# the inclusion of generic Makefile. > > > -ARCH_REL_TYPE_ABS := R_RISCV_32|R_RISCV_64|R_RISCV_JUMP_SLOT > > > include $(srctree)/lib/vdso/Makefile > > > # Symbols present in the vdso > > > vdso-syms = rt_sigreturn > > > > Acked-by: Palmer Dabbelt # RISC-V > > > > Thanks! > > Looks like this patch hasn't been picked yet... > Ping:) -- 宋方睿
[PATCH] powerpc: Remove TM XER[SO] bug workaround on POWER9 v2.3
From: Reza Arbab
When creating the CPU feature bits for DD2.3, I should not have carried
forward CPU_FTR_P9_TM_XER_SO_BUG. That bug is fixed in DD2.3, so remove
the flag.
Fixes: 26b78c81e84c ("powerpc: Enable the DAWR on POWER9 DD2.3 and above")
Signed-off-by: Reza Arbab
---
arch/powerpc/include/asm/cputable.h | 1 -
arch/powerpc/kernel/dt_cpu_ftrs.c | 1 -
2 files changed, 2 deletions(-)
diff --git a/arch/powerpc/include/asm/cputable.h
b/arch/powerpc/include/asm/cputable.h
index 757dbded11dc..5dc6906498ef 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -439,7 +439,6 @@ static inline void cpu_feature_keys_init(void) { }
CPU_FTR_P9_TM_XER_SO_BUG)
#define CPU_FTRS_POWER9_DD2_3 (CPU_FTRS_POWER9 | CPU_FTR_POWER9_DD2_1 | \
CPU_FTR_P9_TM_HV_ASSIST | \
- CPU_FTR_P9_TM_XER_SO_BUG | \
CPU_FTR_DAWR)
#define CPU_FTRS_POWER10 (CPU_FTR_LWSYNC | \
CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | CPU_FTR_ARCH_206 |\
diff --git a/arch/powerpc/kernel/dt_cpu_ftrs.c
b/arch/powerpc/kernel/dt_cpu_ftrs.c
index c3fb9fdf5bd7..afcdbeed8b44 100644
--- a/arch/powerpc/kernel/dt_cpu_ftrs.c
+++ b/arch/powerpc/kernel/dt_cpu_ftrs.c
@@ -782,7 +782,6 @@ static __init void cpufeatures_cpu_quirks(void)
cur_cpu_spec->cpu_features &= ~(CPU_FTR_DAWR);
} else if ((version & 0xefff) == 0x004e0203) {
cur_cpu_spec->cpu_features |= CPU_FTR_P9_TM_HV_ASSIST;
- cur_cpu_spec->cpu_features |= CPU_FTR_P9_TM_XER_SO_BUG;
cur_cpu_spec->cpu_features |= CPU_FTR_POWER9_DD2_1;
} else if ((version & 0x) == 0x004e) {
/* DD2.1 and up have DD2_1 */
---
base-commit: fe15c26ee26efa11741a7b632e9f23b01aca4cc6
change-id: 20230308-cpu_ftr_p9_tm_xer_so_bug-ec58b00a9716
Best regards,
--
Reza Arbab
[PATCH] KVM: PPC: Mark three local functions "static"
Tag a few functions that are local and don't have a previous prototype as
"static".
No functional change intended.
Reported-by: kernel test robot
Link: https://lore.kernel.org/oe-kbuild-all/202303031630.ntviuyqo-...@intel.com
Signed-off-by: Sean Christopherson
---
This was prompted by a new W=1 build warning for a commit that went in
through the KVM tree, but said commit has made its way to Linus, so it
shouldn't matter who grabs this.
arch/powerpc/kvm/booke.c | 5 +++--
arch/powerpc/kvm/e500mc.c | 2 +-
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index 01adffb24667..ce37d282be6d 100644
--- a/arch/powerpc/kvm/booke.c
+++ b/arch/powerpc/kvm/booke.c
@@ -623,7 +623,7 @@ static void arm_next_watchdog(struct kvm_vcpu *vcpu)
spin_unlock_irqrestore(>arch.wdt_lock, flags);
}
-void kvmppc_watchdog_func(struct timer_list *t)
+static void kvmppc_watchdog_func(struct timer_list *t)
{
struct kvm_vcpu *vcpu = from_timer(vcpu, t, arch.wdt_timer);
u32 tsr, new_tsr;
@@ -1946,7 +1946,8 @@ static int kvmppc_booke_add_watchpoint(struct debug_reg
*dbg_reg, uint64_t addr,
dbg_reg->dbcr0 |= DBCR0_IDM;
return 0;
}
-void kvm_guest_protect_msr(struct kvm_vcpu *vcpu, ulong prot_bitmap, bool set)
+static void kvm_guest_protect_msr(struct kvm_vcpu *vcpu, ulong prot_bitmap,
+ bool set)
{
/* XXX: Add similar MSR protection for BookE-PR */
#ifdef CONFIG_KVM_BOOKE_HV
diff --git a/arch/powerpc/kvm/e500mc.c b/arch/powerpc/kvm/e500mc.c
index a309138927ff..d58df71ace58 100644
--- a/arch/powerpc/kvm/e500mc.c
+++ b/arch/powerpc/kvm/e500mc.c
@@ -168,7 +168,7 @@ static void kvmppc_core_vcpu_put_e500mc(struct kvm_vcpu
*vcpu)
kvmppc_booke_vcpu_put(vcpu);
}
-int kvmppc_e500mc_check_processor_compat(void)
+static int kvmppc_e500mc_check_processor_compat(void)
{
int r;
base-commit: 63355b9884b3d1677de6bd1517cd2b8a9bf53978
--
2.40.0.rc1.284.g88254d51c5-goog
Re: [PATCH v10 04/13] dt-bindings: gpio-mmio: Add compatible for QIXIS
On Mon, 06 Mar 2023 14:15:26 -0500, Sean Anderson wrote: > NXP has a "QIXIS" FPGA on several of their reference design boards. On > the LS1088ARDB there are several registers which control GPIOs. These > can be modeled with the MMIO GPIO driver. > > Signed-off-by: Sean Anderson > --- > > Changes in v10: > - New > > .../devicetree/bindings/gpio/gpio-mmio.yaml| 14 ++ > 1 file changed, 10 insertions(+), 4 deletions(-) > Reviewed-by: Rob Herring
Re: [PATCH v10 03/13] dt-bindings: Convert gpio-mmio to yaml
On Mon, Mar 06, 2023 at 02:15:25PM -0500, Sean Anderson wrote:
> This is a generic binding for simple MMIO GPIO controllers. Although we
> have a single driver for these controllers, they were previously spread
> over several files. Consolidate them. The register descriptions are
> adapted from the comments in the source. There is no set order for the
> registers, so I have not specified one.
>
> Signed-off-by: Sean Anderson
> ---
>
> Changes in v10:
> - New
>
> .../bindings/gpio/brcm,bcm6345-gpio.yaml | 16 +--
> .../devicetree/bindings/gpio/gpio-mmio.yaml | 136 ++
> .../bindings/gpio/ni,169445-nand-gpio.txt | 38 -
> .../devicetree/bindings/gpio/wd,mbl-gpio.txt | 38 -
> 4 files changed, 137 insertions(+), 91 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/gpio/gpio-mmio.yaml
> delete mode 100644
> Documentation/devicetree/bindings/gpio/ni,169445-nand-gpio.txt
> delete mode 100644 Documentation/devicetree/bindings/gpio/wd,mbl-gpio.txt
>
> diff --git a/Documentation/devicetree/bindings/gpio/brcm,bcm6345-gpio.yaml
> b/Documentation/devicetree/bindings/gpio/brcm,bcm6345-gpio.yaml
> index 4d69f79df859..e11f4af49c52 100644
> --- a/Documentation/devicetree/bindings/gpio/brcm,bcm6345-gpio.yaml
> +++ b/Documentation/devicetree/bindings/gpio/brcm,bcm6345-gpio.yaml
> @@ -4,7 +4,7 @@
> $id: http://devicetree.org/schemas/gpio/brcm,bcm6345-gpio.yaml#
> $schema: http://devicetree.org/meta-schemas/core.yaml#
>
> -title: Broadcom BCM6345 GPIO controller
> +title: Broadcom BCM63xx GPIO controller
>
> maintainers:
>- Álvaro Fernández Rojas
> @@ -18,8 +18,6 @@ description: |+
>
>BCM6338 have 8-bit data and dirout registers, where GPIO state can be read
>and/or written, and the direction changed from input to output.
> - BCM6345 have 16-bit data and dirout registers, where GPIO state can be read
> - and/or written, and the direction changed from input to output.
>BCM6318, BCM6328, BCM6358, BCM6362, BCM6368 and BCM63268 have 32-bit data
>and dirout registers, where GPIO state can be read and/or written, and the
>direction changed from input to output.
> @@ -29,7 +27,6 @@ properties:
> enum:
>- brcm,bcm6318-gpio
>- brcm,bcm6328-gpio
> - - brcm,bcm6345-gpio
>- brcm,bcm6358-gpio
>- brcm,bcm6362-gpio
>- brcm,bcm6368-gpio
> @@ -63,17 +60,6 @@ required:
> additionalProperties: false
>
> examples:
> - - |
> -gpio@fffe0406 {
> - compatible = "brcm,bcm6345-gpio";
> - reg-names = "dirout", "dat";
> - reg = <0xfffe0406 2>, <0xfffe040a 2>;
> - native-endian;
> -
> - gpio-controller;
> - #gpio-cells = <2>;
> -};
> -
>- |
> gpio@0 {
>compatible = "brcm,bcm63268-gpio";
> diff --git a/Documentation/devicetree/bindings/gpio/gpio-mmio.yaml
> b/Documentation/devicetree/bindings/gpio/gpio-mmio.yaml
> new file mode 100644
> index ..fd5c7055d542
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpio/gpio-mmio.yaml
> @@ -0,0 +1,136 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/gpio/gpio-mmio.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Generic MMIO GPIO
> +
> +maintainers:
> + - Linus Walleij
> + - Bartosz Golaszewski
> +
> +description: |
Don't need '|' unless you want line endings preserved. Elsewhere too.
> + Some simple GPIO controllers may consist of a single data register or a
> pair
> + of set/clear-bit registers. Such controllers are common for glue logic in
> + FPGAs or ASICs. Commonly, these controllers are accessed over memory-mapped
> + NAND-style parallel busses.
> +
> +properties:
> + big-endian:
> +true
big-endian: true
> +
> + compatible:
> +enum:
> + - brcm,bcm6345-gpio # Broadcom BCM6345 GPIO controller
> + - wd,mbl-gpio # Western Digital MyBook Live memory-mapped GPIO
> controller
> + - ni,169445-nand-gpio # National Instruments 169445 GPIO NAND
> controller
> +
> + '#gpio-cells':
> +const: 2
> +
> + gpio-controller:
> +true
ditto.
> +
> + reg:
> +minItems: 1
> +description: |
> + A list of registers in the controller. The width of each register is
> + determined by its size. All registers must have the same width. The
> number
> + of GPIOs is set by the width, with bit 0 corresponding to GPIO 0.
> +items:
> + - description: |
> + Register to READ the value of the GPIO lines. If GPIO line is high,
> + the bit will be set. If the GPIO line is low, the bit will be
> cleared.
> + This register may also be used to drive GPIOs if the SET register
> is
> + omitted.
> + - description: |
> + Register to SET the value of the GPIO lines. Setting a bit in this
> + register will drive the GPIO line high.
> + - description: |
> + Register to
Re: [PATCH] PCI/AER: correctable error message as KERN_INFO
On Wed, Mar 8, 2023 at 12:18 PM Bjorn Helgaas wrote:
>
> On Wed, Mar 08, 2023 at 12:00:48PM -0800, Grant Grundler wrote:
> > Ping? Did I miss an email or other work that this patch collides with?
>
> Nope, we typically make topic branches based on -rc1, so not much
> happens during the merge window. -rc1 was tagged Sunday, so things
> will start appearing in -next soon.
Ah ok! Thanks for clarifying Bjorn!
cheers,
grant
>
> Bjorn
>
> > On Tue, Feb 28, 2023 at 10:05 PM Grant Grundler
> > wrote:
> > >
> > > Since correctable errors have been corrected (and counted), the dmesg
> > > output
> > > should not be reported as a warning, but rather as "informational".
> > >
> > > Otherwise, using a certain well known vendor's PCIe parts in a USB4
> > > docking
> > > station, the dmesg buffer can be spammed with correctable errors, 717
> > > bytes
> > > per instance, potentially many MB per day.
> > >
> > > Given the "WARN" priority, these messages have already confused the
> > > typical
> > > user that stumbles across them, support staff (triaging feedback reports),
> > > and more than a few linux kernel devs. Changing to INFO will hide these
> > > messages from most audiences.
> > >
> > > Signed-off-by: Grant Grundler
> > > ---
> > > This patch will likely conflict with:
> > >
> > > https://lore.kernel.org/all/20230103165548.570377-1-rajat.khandel...@linux.intel.com/
> > >
> > > which I'd also like to see upstream. Please let me know to resubmit mine
> > > if Rajat's patch lands first. Or feel free to fix up this one.
> > >
> > > drivers/pci/pcie/aer.c | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
> > > index f6c24ded134c..e4cf3ec40d66 100644
> > > --- a/drivers/pci/pcie/aer.c
> > > +++ b/drivers/pci/pcie/aer.c
> > > @@ -692,7 +692,7 @@ static void __aer_print_error(struct pci_dev *dev,
> > >
> > > if (info->severity == AER_CORRECTABLE) {
> > > strings = aer_correctable_error_string;
> > > - level = KERN_WARNING;
> > > + level = KERN_INFO;
> > > } else {
> > > strings = aer_uncorrectable_error_string;
> > > level = KERN_ERR;
> > > @@ -724,7 +724,7 @@ void aer_print_error(struct pci_dev *dev, struct
> > > aer_err_info *info)
> > > layer = AER_GET_LAYER_ERROR(info->severity, info->status);
> > > agent = AER_GET_AGENT(info->severity, info->status);
> > >
> > > - level = (info->severity == AER_CORRECTABLE) ? KERN_WARNING :
> > > KERN_ERR;
> > > + level = (info->severity == AER_CORRECTABLE) ? KERN_INFO :
> > > KERN_ERR;
> > >
> > > pci_printk(level, dev, "PCIe Bus Error: severity=%s, type=%s,
> > > (%s)\n",
> > >aer_error_severity_string[info->severity],
> > > --
> > > 2.39.2.722.g9855ee24e9-goog
> > >
Re: [PATCH] PCI/AER: correctable error message as KERN_INFO
On Wed, Mar 08, 2023 at 12:00:48PM -0800, Grant Grundler wrote:
> Ping? Did I miss an email or other work that this patch collides with?
Nope, we typically make topic branches based on -rc1, so not much
happens during the merge window. -rc1 was tagged Sunday, so things
will start appearing in -next soon.
Bjorn
> On Tue, Feb 28, 2023 at 10:05 PM Grant Grundler wrote:
> >
> > Since correctable errors have been corrected (and counted), the dmesg output
> > should not be reported as a warning, but rather as "informational".
> >
> > Otherwise, using a certain well known vendor's PCIe parts in a USB4 docking
> > station, the dmesg buffer can be spammed with correctable errors, 717 bytes
> > per instance, potentially many MB per day.
> >
> > Given the "WARN" priority, these messages have already confused the typical
> > user that stumbles across them, support staff (triaging feedback reports),
> > and more than a few linux kernel devs. Changing to INFO will hide these
> > messages from most audiences.
> >
> > Signed-off-by: Grant Grundler
> > ---
> > This patch will likely conflict with:
> >
> > https://lore.kernel.org/all/20230103165548.570377-1-rajat.khandel...@linux.intel.com/
> >
> > which I'd also like to see upstream. Please let me know to resubmit mine if
> > Rajat's patch lands first. Or feel free to fix up this one.
> >
> > drivers/pci/pcie/aer.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
> > index f6c24ded134c..e4cf3ec40d66 100644
> > --- a/drivers/pci/pcie/aer.c
> > +++ b/drivers/pci/pcie/aer.c
> > @@ -692,7 +692,7 @@ static void __aer_print_error(struct pci_dev *dev,
> >
> > if (info->severity == AER_CORRECTABLE) {
> > strings = aer_correctable_error_string;
> > - level = KERN_WARNING;
> > + level = KERN_INFO;
> > } else {
> > strings = aer_uncorrectable_error_string;
> > level = KERN_ERR;
> > @@ -724,7 +724,7 @@ void aer_print_error(struct pci_dev *dev, struct
> > aer_err_info *info)
> > layer = AER_GET_LAYER_ERROR(info->severity, info->status);
> > agent = AER_GET_AGENT(info->severity, info->status);
> >
> > - level = (info->severity == AER_CORRECTABLE) ? KERN_WARNING :
> > KERN_ERR;
> > + level = (info->severity == AER_CORRECTABLE) ? KERN_INFO : KERN_ERR;
> >
> > pci_printk(level, dev, "PCIe Bus Error: severity=%s, type=%s,
> > (%s)\n",
> >aer_error_severity_string[info->severity],
> > --
> > 2.39.2.722.g9855ee24e9-goog
> >
Re: [PATCH] PCI/AER: correctable error message as KERN_INFO
Ping? Did I miss an email or other work that this patch collides with?
cheers,
grant
On Tue, Feb 28, 2023 at 10:05 PM Grant Grundler wrote:
>
> Since correctable errors have been corrected (and counted), the dmesg output
> should not be reported as a warning, but rather as "informational".
>
> Otherwise, using a certain well known vendor's PCIe parts in a USB4 docking
> station, the dmesg buffer can be spammed with correctable errors, 717 bytes
> per instance, potentially many MB per day.
>
> Given the "WARN" priority, these messages have already confused the typical
> user that stumbles across them, support staff (triaging feedback reports),
> and more than a few linux kernel devs. Changing to INFO will hide these
> messages from most audiences.
>
> Signed-off-by: Grant Grundler
> ---
> This patch will likely conflict with:
>
> https://lore.kernel.org/all/20230103165548.570377-1-rajat.khandel...@linux.intel.com/
>
> which I'd also like to see upstream. Please let me know to resubmit mine if
> Rajat's patch lands first. Or feel free to fix up this one.
>
> drivers/pci/pcie/aer.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
> index f6c24ded134c..e4cf3ec40d66 100644
> --- a/drivers/pci/pcie/aer.c
> +++ b/drivers/pci/pcie/aer.c
> @@ -692,7 +692,7 @@ static void __aer_print_error(struct pci_dev *dev,
>
> if (info->severity == AER_CORRECTABLE) {
> strings = aer_correctable_error_string;
> - level = KERN_WARNING;
> + level = KERN_INFO;
> } else {
> strings = aer_uncorrectable_error_string;
> level = KERN_ERR;
> @@ -724,7 +724,7 @@ void aer_print_error(struct pci_dev *dev, struct
> aer_err_info *info)
> layer = AER_GET_LAYER_ERROR(info->severity, info->status);
> agent = AER_GET_AGENT(info->severity, info->status);
>
> - level = (info->severity == AER_CORRECTABLE) ? KERN_WARNING : KERN_ERR;
> + level = (info->severity == AER_CORRECTABLE) ? KERN_INFO : KERN_ERR;
>
> pci_printk(level, dev, "PCIe Bus Error: severity=%s, type=%s, (%s)\n",
>aer_error_severity_string[info->severity],
> --
> 2.39.2.722.g9855ee24e9-goog
>
Re: [PATCH] mm: add PTE pointer parameter to flush_tlb_fix_spurious_fault()
On 06.03.23 17:15, Gerald Schaefer wrote: s390 can do more fine-grained handling of spurious TLB protection faults, when there also is the PTE pointer available. Therefore, pass on the PTE pointer to flush_tlb_fix_spurious_fault() as an additional parameter. This will add no functional change to other architectures, but those with private flush_tlb_fix_spurious_fault() implementations need to be made aware of the new parameter. Reviewed-by: Alexander Gordeev Signed-off-by: Gerald Schaefer --- Acked-by: David Hildenbrand -- Thanks, David / dhildenb
Re: [PATCH v4 1/2] powerpc/mm: Support execute-only memory on the Radix MMU
Hello, On Wed, Aug 31, 2022 at 11:13:59PM +1000, Michael Ellerman wrote: > On Wed, 17 Aug 2022 15:06:39 +1000, Russell Currey wrote: > > Add support for execute-only memory (XOM) for the Radix MMU by using an > > execute-only mapping, as opposed to the RX mapping used by powerpc's > > other MMUs. > > > > The Hash MMU already supports XOM through the execute-only pkey, > > which is a separate mechanism shared with x86. A PROT_EXEC-only mapping > > will map to RX, and then the pkey will be applied on top of it. > > > > [...] > > Applied to powerpc/next. > > [1/2] powerpc/mm: Support execute-only memory on the Radix MMU > > https://git.kernel.org/powerpc/c/395cac7752b905318ae454a8b859d4c190485510 This breaks libaio tests (on POWER9 hash PowerVM): https://pagure.io/libaio/blob/master/f/harness/cases/5.t#_43 cases/5.p expect 512: (w), res = 512 [Success] expect 512: (r), res = 512 [Success] expect 512: (r), res = 512 [Success] expect 512: (w), res = 512 [Success] expect 512: (w), res = 512 [Success] expect -14: (r), res = -14 [Bad address] expect 512: (r), res = 512 [Success] expect 512: (w), res = 512 [Success] test cases/5.t completed PASSED. cases/5.p expect 512: (w), res = 512 [Success] expect 512: (r), res = 512 [Success] expect 512: (r), res = 512 [Success] expect 512: (w), res = 512 [Success] expect 512: (w), res = 512 [Success] expect -14: (r), res = -14 [Bad address] expect 512: (r), res = 512 [Success] expect -14: (w), res = 512 [Success] -- FAILED test cases/5.t completed FAILED. Can you have a look if that test assumption is OK? Thanks Michal
[PATCH v4 3/4] arch/*/io.h: remove ioremap_uc in some architectures
ioremap_uc() is only meaningful on old x86-32 systems with the PAT
extension, and on ia64 with its slightly unconventional ioremap()
behavior. So remove the ioremap_uc() definition in architecutures
other than x86 and ia64. These architectures all have asm-generic/io.h
included and will have the default ioremap_uc() definition which
returns NULL.
This changes the existing behaviour, while no need to worry about
any breakage because in the only callsite of ioremap_uc(), code
has been adjusted to eliminate the impact. Please see
atyfb_setup_generic() of drivers/video/fbdev/aty/atyfb_base.c.
If any new invocation of ioremap_uc() need be added, please consider
using ioremap() intead or adding a ARCH specific version if necessary.
Acked-by: Geert Uytterhoeven
Signed-off-by: Baoquan He
Cc: linux-al...@vger.kernel.org
Cc: linux-hexa...@vger.kernel.org
Cc: linux-m...@lists.linux-m68k.org
Cc: linux-m...@vger.kernel.org
Cc: linux-par...@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux...@vger.kernel.org
Cc: sparcli...@vger.kernel.org
---
Documentation/driver-api/device-io.rst | 9 +
arch/alpha/include/asm/io.h| 1 -
arch/hexagon/include/asm/io.h | 3 ---
arch/m68k/include/asm/kmap.h | 1 -
arch/mips/include/asm/io.h | 1 -
arch/parisc/include/asm/io.h | 2 --
arch/powerpc/include/asm/io.h | 1 -
arch/sh/include/asm/io.h | 2 --
arch/sparc/include/asm/io_64.h | 1 -
9 files changed, 5 insertions(+), 16 deletions(-)
diff --git a/Documentation/driver-api/device-io.rst
b/Documentation/driver-api/device-io.rst
index 4d2baac0311c..d55384b106bd 100644
--- a/Documentation/driver-api/device-io.rst
+++ b/Documentation/driver-api/device-io.rst
@@ -408,11 +408,12 @@ functions for details on the CPU side of things.
ioremap_uc()
-ioremap_uc() behaves like ioremap() except that on the x86 architecture without
-'PAT' mode, it marks memory as uncached even when the MTRR has designated
-it as cacheable, see Documentation/x86/pat.rst.
+ioremap_uc() is only meaningful on old x86-32 systems with the PAT extension,
+and on ia64 with its slightly unconventional ioremap() behavior, everywhere
+elss ioremap_uc() defaults to return NULL.
-Portable drivers should avoid the use of ioremap_uc().
+
+Portable drivers should avoid the use of ioremap_uc(), use ioremap() instead.
ioremap_cache()
---
diff --git a/arch/alpha/include/asm/io.h b/arch/alpha/include/asm/io.h
index 7aeaf7c30a6f..076f0e4e7f1e 100644
--- a/arch/alpha/include/asm/io.h
+++ b/arch/alpha/include/asm/io.h
@@ -308,7 +308,6 @@ static inline void __iomem *ioremap(unsigned long port,
unsigned long size)
}
#define ioremap_wc ioremap
-#define ioremap_uc ioremap
static inline void iounmap(volatile void __iomem *addr)
{
diff --git a/arch/hexagon/include/asm/io.h b/arch/hexagon/include/asm/io.h
index dcd9cbbf5934..b9847472f25c 100644
--- a/arch/hexagon/include/asm/io.h
+++ b/arch/hexagon/include/asm/io.h
@@ -176,9 +176,6 @@ static inline void writel(u32 data, volatile void __iomem
*addr)
#define _PAGE_IOREMAP (_PAGE_PRESENT | _PAGE_READ | _PAGE_WRITE | \
(__HEXAGON_C_DEV << 6))
-#define ioremap_uc(addr, size) ioremap((addr), (size))
-
-
#define __raw_writel writel
static inline void memcpy_fromio(void *dst, const volatile void __iomem *src,
diff --git a/arch/m68k/include/asm/kmap.h b/arch/m68k/include/asm/kmap.h
index 4efb3efa593a..b778f015c917 100644
--- a/arch/m68k/include/asm/kmap.h
+++ b/arch/m68k/include/asm/kmap.h
@@ -25,7 +25,6 @@ static inline void __iomem *ioremap(unsigned long physaddr,
unsigned long size)
return __ioremap(physaddr, size, IOMAP_NOCACHE_SER);
}
-#define ioremap_uc ioremap
#define ioremap_wt ioremap_wt
static inline void __iomem *ioremap_wt(unsigned long physaddr,
unsigned long size)
diff --git a/arch/mips/include/asm/io.h b/arch/mips/include/asm/io.h
index 6756baadba6c..da0a625c3c6d 100644
--- a/arch/mips/include/asm/io.h
+++ b/arch/mips/include/asm/io.h
@@ -167,7 +167,6 @@ void iounmap(const volatile void __iomem *addr);
*/
#define ioremap(offset, size) \
ioremap_prot((offset), (size), _CACHE_UNCACHED)
-#define ioremap_uc ioremap
/*
* ioremap_cache - map bus memory into CPU space
diff --git a/arch/parisc/include/asm/io.h b/arch/parisc/include/asm/io.h
index 366537042465..48630c78714a 100644
--- a/arch/parisc/include/asm/io.h
+++ b/arch/parisc/include/asm/io.h
@@ -132,8 +132,6 @@ static inline void gsc_writeq(unsigned long long val,
unsigned long addr)
#define ioremap_wc(addr, size) \
ioremap_prot((addr), (size), _PAGE_IOREMAP)
-#define ioremap_uc(addr, size) \
- ioremap_prot((addr), (size), _PAGE_IOREMAP)
#define pci_iounmappci_iounmap
diff --git a/arch/powerpc/include/asm/io.h b/arch/powerpc/include/asm/io.h
Re: [PATCH v10 03/13] dt-bindings: Convert gpio-mmio to yaml
On 07/03/2023 16:35, Sean Anderson wrote: > Hi Krzysztof, > > On 3/7/23 03:42, Krzysztof Kozlowski wrote: >> On 06/03/2023 20:15, Sean Anderson wrote: >>> This is a generic binding for simple MMIO GPIO controllers. Although we >>> have a single driver for these controllers, they were previously spread >>> over several files. Consolidate them. The register descriptions are >>> adapted from the comments in the source. There is no set order for the >>> registers, so I have not specified one. >>> >>> Signed-off-by: Sean Anderson >>> --- >>> >>> Changes in v10: >>> - New >>> >>> .../bindings/gpio/brcm,bcm6345-gpio.yaml | 16 +-- >>> .../devicetree/bindings/gpio/gpio-mmio.yaml | 136 ++ >>> .../bindings/gpio/ni,169445-nand-gpio.txt | 38 - >>> .../devicetree/bindings/gpio/wd,mbl-gpio.txt | 38 - >>> 4 files changed, 137 insertions(+), 91 deletions(-) >>> create mode 100644 Documentation/devicetree/bindings/gpio/gpio-mmio.yaml >>> delete mode 100644 >>> Documentation/devicetree/bindings/gpio/ni,169445-nand-gpio.txt >>> delete mode 100644 Documentation/devicetree/bindings/gpio/wd,mbl-gpio.txt >> >> https://lore.kernel.org/all/20230126-gpio-mmio-fix-v2-1-38397aace...@ncr.com/ > > Thanks for linking to that. > > I believe this patch should be applied instead of that one because > > - It documents all the registers, which were previously only documented > in the driver > - It handles the endianness properties. > - It consolidates the various descriptions of this binding into one > schema. Sure, sounds reasonable. You can just quickly check if my other comments apply here as well (but seems not): https://lore.kernel.org/all/4df3ec7a-e4af-89bc-9eda-21150395a...@linaro.org/ Best regards, Krzysztof
