Linux-stable-mirror

linux-stable-mirror@lists.linaro.org

305 participants
124187 discussions

[PATCH 5.4] net: dsa: mt7530: set CPU port to fallback mode

by DENG Qingfang

[ Upstream commit 38152ea37d8bdaffa22603e0a5b5b86cfa8714c9 ] Currently, setting a bridge's self PVID to other value and deleting the default VID 1 renders untagged ports of that VLAN unable to talk to the CPU port: bridge vlan add dev br0 vid 2 pvid untagged self bridge vlan del dev br0 vid 1 self bridge vlan add dev sw0p0 vid 2 pvid untagged bridge vlan del dev sw0p0 vid 1 # br0 cannot send untagged frames out of sw0p0 anymore That is because the CPU port is set to security mode and its PVID is still 1, and untagged frames are dropped due to VLAN member violation. Set the CPU port to fallback mode so untagged frames can pass through. Fixes: 83163f7dca56 ("net: dsa: mediatek: add VLAN support for MT7530") Signed-off-by: DENG Qingfang <dqfext(a)gmail.com> Reviewed-by: Florian Fainelli <f.fainelli(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> --- drivers/net/dsa/mt7530.c | 11 ++++++++--- drivers/net/dsa/mt7530.h | 6 ++++++ 2 files changed, 14 insertions(+), 3 deletions(-) diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c index cffaf4fdd772..7b81a39c15c1 100644 --- a/drivers/net/dsa/mt7530.c +++ b/drivers/net/dsa/mt7530.c @@ -821,10 +821,15 @@ mt7530_port_set_vlan_aware(struct dsa_switch *ds, int port) PCR_MATRIX_MASK, PCR_MATRIX(MT7530_ALL_MEMBERS)); /* Trapped into security mode allows packet forwarding through VLAN - * table lookup. + * table lookup. CPU port is set to fallback mode to let untagged + * frames pass through. */ - mt7530_rmw(priv, MT7530_PCR_P(port), PCR_PORT_VLAN_MASK, - MT7530_PORT_SECURITY_MODE); + if (dsa_is_cpu_port(ds, port)) + mt7530_rmw(priv, MT7530_PCR_P(port), PCR_PORT_VLAN_MASK, + MT7530_PORT_FALLBACK_MODE); + else + mt7530_rmw(priv, MT7530_PCR_P(port), PCR_PORT_VLAN_MASK, + MT7530_PORT_SECURITY_MODE); /* Set the port as a user port which is to be able to recognize VID * from incoming packets before fetching entry within the VLAN table. diff --git a/drivers/net/dsa/mt7530.h b/drivers/net/dsa/mt7530.h index 756140b7dfd5..f8d5e82ddab2 100644 --- a/drivers/net/dsa/mt7530.h +++ b/drivers/net/dsa/mt7530.h @@ -147,6 +147,12 @@ enum mt7530_port_mode { /* Port Matrix Mode: Frames are forwarded by the PCR_MATRIX members. */ MT7530_PORT_MATRIX_MODE = PORT_VLAN(0), + /* Fallback Mode: Forward received frames with ingress ports that do + * not belong to the VLAN member. Frames whose VID is not listed on + * the VLAN table are forwarded by the PCR_MATRIX members. + */ + MT7530_PORT_FALLBACK_MODE = PORT_VLAN(1), + /* Security Mode: Discard any frame due to ingress membership * violation or VID missed on the VLAN table. */ -- 2.26.2

5 years, 7 months

stable/linux-4.9.y boot: 60 boots: 1 failed, 55 passed with 4 untried/unknown (v4.9.225)

by kernelci.org bot

****************************************** * WARNING: Boot tests are now deprecated * ****************************************** As kernelci.org is expanding its functional testing capabilities, the concept of boot testing is now deprecated. Boot results are scheduled to be dropped on *5th June 2020*. The full schedule for boot tests deprecation is available on this GitHub issue: https://github.com/kernelci/kernelci-backend/issues/238 The new equivalent is the *baseline* test suite which also runs sanity checks using dmesg and bootrr: https://github.com/kernelci/bootrr See the *baseline results for this kernel revision* on this page: https://kernelci.org/test/job/stable/branch/linux-4.9.y/kernel/v4.9.225/pla… ------------------------------------------------------------------------------- stable/linux-4.9.y boot: 60 boots: 1 failed, 55 passed with 4 untried/unknown (v4.9.225) Full Boot Summary: https://kernelci.org/boot/all/job/stable/branch/linux-4.9.y/kernel/v4.9.225/ Full Build Summary: https://kernelci.org/build/stable/branch/linux-4.9.y/kernel/v4.9.225/ Tree: stable Branch: linux-4.9.y Git Describe: v4.9.225 Git Commit: 82dddebfe7da9d2670977ab723da2fdac3eff5b0 Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git Tested: 32 unique boards, 12 SoC families, 10 builds out of 156 Boot Failure Detected: arm: sama5_defconfig: gcc-8: at91-sama5d4_xplained: 1 failed lab --- For more info write to <info(a)kernelci.org>

5 years, 7 months

[PATCH v3 2/4] pwm: jz4740: Enhance precision in calculation of duty cycle

by Paul Cercueil

Calculating the hardware value for the duty from the hardware value of the period resulted in a precision loss versus calculating it from the clock rate directly. (Also remove a cast that doesn't really need to be here) Fixes: f6b8a5700057 ("pwm: Add Ingenic JZ4740 support") Cc: <stable(a)vger.kernel.org> Suggested-by: Uwe Kleine-König <u.kleine-koenig(a)pengutronix.de> Reviewed-by: Uwe Kleine-König <u.kleine-koenig(a)pengutronix.de> Signed-off-by: Paul Cercueil <paul(a)crapouillou.net> --- Notes: v2: New patch. I don't consider this a fix but an enhancement, since the old behaviour was in place since the driver was born in ~2010, so no Fixes tag. v3: Add Fixes tag and Uwe's Reviewed-by drivers/pwm/pwm-jz4740.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/pwm/pwm-jz4740.c b/drivers/pwm/pwm-jz4740.c index 3cd5c054ad9a..4fe9d99ac9a9 100644 --- a/drivers/pwm/pwm-jz4740.c +++ b/drivers/pwm/pwm-jz4740.c @@ -158,11 +158,11 @@ static int jz4740_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm, /* Calculate period value */ tmp = (unsigned long long)rate * state->period; do_div(tmp, NSEC_PER_SEC); - period = (unsigned long)tmp; + period = tmp; /* Calculate duty value */ - tmp = (unsigned long long)period * state->duty_cycle; - do_div(tmp, state->period); + tmp = (unsigned long long)rate * state->duty_cycle; + do_div(tmp, NSEC_PER_SEC); duty = period - tmp; if (duty >= period) -- 2.26.2

5 years, 7 months

[patch 4/5] fs/binfmt_elf.c: allocate initialized memory in fill_thread_core_info()

by Andrew Morton

From: Alexander Potapenko <glider(a)google.com> Subject: fs/binfmt_elf.c: allocate initialized memory in fill_thread_core_info() KMSAN reported uninitialized data being written to disk when dumping core. As a result, several kilobytes of kmalloc memory may be written to the core file and then read by a non-privileged user. Link: http://lkml.kernel.org/r/20200419100848.63472-1-glider@google.com Link: https://github.com/google/kmsan/issues/76 Signed-off-by: Alexander Potapenko <glider(a)google.com> Reported-by: sam <sunhaoyl(a)outlook.com> Acked-by: Kees Cook <keescook(a)chromium.org> Cc: Al Viro <viro(a)zeniv.linux.org.uk> Cc: Alexey Dobriyan <adobriyan(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/binfmt_elf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/fs/binfmt_elf.c~fs-binfmt_elfc-allocate-initialized-memory-in-fill_thread_core_info +++ a/fs/binfmt_elf.c @@ -1733,7 +1733,7 @@ static int fill_thread_core_info(struct (!regset->active || regset->active(t->task, regset) > 0)) { int ret; size_t size = regset_size(t->task, regset); - void *data = kmalloc(size, GFP_KERNEL); + void *data = kzalloc(size, GFP_KERNEL); if (unlikely(!data)) return 0; ret = regset->get(t->task, regset, _

5 years, 7 months

Re: [PATCH v3] airo: Fix read overflows sending packets

by Sasha Levin

Hi [This is an automated email] This commit has been processed because it contains a -stable tag. The stable tag indicates that it's relevant for the following trees: all The bot has tested the following trees: v5.6.14, v5.4.42, v4.19.124, v4.14.181, v4.9.224, v4.4.224. v5.6.14: Build OK! v5.4.42: Build OK! v4.19.124: Build OK! v4.14.181: Build OK! v4.9.224: Build OK! v4.4.224: Failed to apply! Possible dependencies: Unable to calculate NOTE: The patch will not be queued to stable trees until it is upstream. How should we proceed with this patch? -- Thanks Sasha

5 years, 7 months

[PATCHES] Networking

by David Miller

Please queue up the following networking bug fixes for v5.4 and v5.6 -stable, respectively. Thank you.

5 years, 7 months

[PATCH 1/3] KVM: arm64: Stop writing aarch32's CSSELR into ACTLR

by James Morse

aarch32 has pairs of registers to access the high and low parts of 64bit registers. KVM has a union of 64bit sys_regs[] and 32bit copro[]. The 32bit accessors read the high or low part of the 64bit sys_reg[] value through the union. Both sys_reg_descs[] and cp15_regs[] list access_csselr() as the accessor for CSSELR{,_EL1}. access_csselr() is only aware of the 64bit sys_regs[], and expects r->reg to be 'CSSELR_EL1' in the enum, index 2 of the 64bit array. cp15_regs[] uses the 32bit copro[] alias of sys_regs[]. Here CSSELR is c0_CSSELR which is the same location in sys_reg[]. r->reg is 'c0_CSSELR', index 4 in the 32bit array. access_csselr() uses the 32bit r->reg value to access the 64bit array, so reads and write the wrong value. sys_regs[4], is ACTLR_EL1, which is subsequently save/restored when we enter the guest. ACTLR_EL1 is supposed to be read-only for the guest. This register only affects execution at EL1, and the host's value is restored before we return to host EL1. Rename access_csselr() to access_csselr_el1(), to indicate it expects the 64bit register index, and pass it CSSELR_EL1 from cp15_regs[]. Cc: stable(a)vger.kernel.org Signed-off-by: James Morse <james.morse(a)arm.com> ---- Providing access_csselr_cp15() wouldn't work as with VHE CSSELR_EL1 is loaded on the CPU while this code runs. access_csselr_cp15() would have to map it back the 64bit resgister to use vcpu_write_sys_reg(). We may as well do it in the table. arch/arm64/kvm/sys_regs.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c index 51db934702b6..2eda539f3281 100644 --- a/arch/arm64/kvm/sys_regs.c +++ b/arch/arm64/kvm/sys_regs.c @@ -1302,7 +1302,7 @@ static bool access_clidr(struct kvm_vcpu *vcpu, struct sys_reg_params *p, return true; } -static bool access_csselr(struct kvm_vcpu *vcpu, struct sys_reg_params *p, +static bool access_csselr_el1(struct kvm_vcpu *vcpu, struct sys_reg_params *p, const struct sys_reg_desc *r) { if (p->is_write) @@ -1566,7 +1566,7 @@ static const struct sys_reg_desc sys_reg_descs[] = { { SYS_DESC(SYS_CCSIDR_EL1), access_ccsidr }, { SYS_DESC(SYS_CLIDR_EL1), access_clidr }, - { SYS_DESC(SYS_CSSELR_EL1), access_csselr, reset_unknown, CSSELR_EL1 }, + { SYS_DESC(SYS_CSSELR_EL1), access_csselr_el1, reset_unknown, CSSELR_EL1 }, { SYS_DESC(SYS_CTR_EL0), access_ctr }, { SYS_DESC(SYS_PMCR_EL0), access_pmcr, reset_pmcr, PMCR_EL0 }, @@ -2060,7 +2060,7 @@ static const struct sys_reg_desc cp15_regs[] = { { Op1(1), CRn( 0), CRm( 0), Op2(0), access_ccsidr }, { Op1(1), CRn( 0), CRm( 0), Op2(1), access_clidr }, - { Op1(2), CRn( 0), CRm( 0), Op2(0), access_csselr, NULL, c0_CSSELR }, + { Op1(2), CRn( 0), CRm( 0), Op2(0), access_csselr_el1, NULL, CSSELR_EL1 }, }; static const struct sys_reg_desc cp15_64_regs[] = { -- 2.20.1

5 years, 7 months

[PATCH AUTOSEL 4.4 1/7] ARC: Fix ICCM & DCCM runtime size checks

by Sasha Levin

From: Eugeniy Paltsev <Eugeniy.Paltsev(a)synopsys.com> [ Upstream commit 43900edf67d7ef3ac8909854d75b8a1fba2d570c ] As of today the ICCM and DCCM size checks are incorrectly using mismatched units (KiB checked against bytes). The CONFIG_ARC_DCCM_SZ and CONFIG_ARC_ICCM_SZ are in KiB, but the size calculated in runtime and stored in cpu->dccm.sz and cpu->iccm.sz is in bytes. Fix that. Reported-by: Paul Greco <pmgreco(a)us.ibm.com> Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev(a)synopsys.com> Signed-off-by: Vineet Gupta <vgupta(a)synopsys.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- arch/arc/kernel/setup.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/arc/kernel/setup.c b/arch/arc/kernel/setup.c index 3013f3f82b95..66e4dc8bce1d 100644 --- a/arch/arc/kernel/setup.c +++ b/arch/arc/kernel/setup.c @@ -12,6 +12,7 @@ #include <linux/root_dev.h> #include <linux/console.h> #include <linux/module.h> +#include <linux/sizes.h> #include <linux/cpu.h> #include <linux/clk-provider.h> #include <linux/of_fdt.h> @@ -308,12 +309,12 @@ static void arc_chk_core_config(void) if ((unsigned int)__arc_dccm_base != cpu->dccm.base_addr) panic("Linux built with incorrect DCCM Base address\n"); - if (CONFIG_ARC_DCCM_SZ != cpu->dccm.sz) + if (CONFIG_ARC_DCCM_SZ * SZ_1K != cpu->dccm.sz) panic("Linux built with incorrect DCCM Size\n"); #endif #ifdef CONFIG_ARC_HAS_ICCM - if (CONFIG_ARC_ICCM_SZ != cpu->iccm.sz) + if (CONFIG_ARC_ICCM_SZ * SZ_1K != cpu->iccm.sz) panic("Linux built with incorrect ICCM Size\n"); #endif -- 2.25.1

5 years, 7 months

[PATCH AUTOSEL 4.9 1/9] ARC: Fix ICCM & DCCM runtime size checks

by Sasha Levin

From: Eugeniy Paltsev <Eugeniy.Paltsev(a)synopsys.com> [ Upstream commit 43900edf67d7ef3ac8909854d75b8a1fba2d570c ] As of today the ICCM and DCCM size checks are incorrectly using mismatched units (KiB checked against bytes). The CONFIG_ARC_DCCM_SZ and CONFIG_ARC_ICCM_SZ are in KiB, but the size calculated in runtime and stored in cpu->dccm.sz and cpu->iccm.sz is in bytes. Fix that. Reported-by: Paul Greco <pmgreco(a)us.ibm.com> Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev(a)synopsys.com> Signed-off-by: Vineet Gupta <vgupta(a)synopsys.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- arch/arc/kernel/setup.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/arc/kernel/setup.c b/arch/arc/kernel/setup.c index 9f96120eee6e..82464fae7772 100644 --- a/arch/arc/kernel/setup.c +++ b/arch/arc/kernel/setup.c @@ -12,6 +12,7 @@ #include <linux/root_dev.h> #include <linux/console.h> #include <linux/module.h> +#include <linux/sizes.h> #include <linux/cpu.h> #include <linux/of_fdt.h> #include <linux/of.h> @@ -333,12 +334,12 @@ static void arc_chk_core_config(void) if ((unsigned int)__arc_dccm_base != cpu->dccm.base_addr) panic("Linux built with incorrect DCCM Base address\n"); - if (CONFIG_ARC_DCCM_SZ != cpu->dccm.sz) + if (CONFIG_ARC_DCCM_SZ * SZ_1K != cpu->dccm.sz) panic("Linux built with incorrect DCCM Size\n"); #endif #ifdef CONFIG_ARC_HAS_ICCM - if (CONFIG_ARC_ICCM_SZ != cpu->iccm.sz) + if (CONFIG_ARC_ICCM_SZ * SZ_1K != cpu->iccm.sz) panic("Linux built with incorrect ICCM Size\n"); #endif -- 2.25.1

5 years, 7 months

[PATCH AUTOSEL 4.14 01/13] ARC: Fix ICCM & DCCM runtime size checks

by Sasha Levin

From: Eugeniy Paltsev <Eugeniy.Paltsev(a)synopsys.com> [ Upstream commit 43900edf67d7ef3ac8909854d75b8a1fba2d570c ] As of today the ICCM and DCCM size checks are incorrectly using mismatched units (KiB checked against bytes). The CONFIG_ARC_DCCM_SZ and CONFIG_ARC_ICCM_SZ are in KiB, but the size calculated in runtime and stored in cpu->dccm.sz and cpu->iccm.sz is in bytes. Fix that. Reported-by: Paul Greco <pmgreco(a)us.ibm.com> Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev(a)synopsys.com> Signed-off-by: Vineet Gupta <vgupta(a)synopsys.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- arch/arc/kernel/setup.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/arc/kernel/setup.c b/arch/arc/kernel/setup.c index 6b8d106e0d53..11c2c4a3fe69 100644 --- a/arch/arc/kernel/setup.c +++ b/arch/arc/kernel/setup.c @@ -15,6 +15,7 @@ #include <linux/clocksource.h> #include <linux/console.h> #include <linux/module.h> +#include <linux/sizes.h> #include <linux/cpu.h> #include <linux/of_fdt.h> #include <linux/of.h> @@ -355,12 +356,12 @@ static void arc_chk_core_config(void) if ((unsigned int)__arc_dccm_base != cpu->dccm.base_addr) panic("Linux built with incorrect DCCM Base address\n"); - if (CONFIG_ARC_DCCM_SZ != cpu->dccm.sz) + if (CONFIG_ARC_DCCM_SZ * SZ_1K != cpu->dccm.sz) panic("Linux built with incorrect DCCM Size\n"); #endif #ifdef CONFIG_ARC_HAS_ICCM - if (CONFIG_ARC_ICCM_SZ != cpu->iccm.sz) + if (CONFIG_ARC_ICCM_SZ * SZ_1K != cpu->iccm.sz) panic("Linux built with incorrect ICCM Size\n"); #endif -- 2.25.1

5 years, 7 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror