October 2021 - Linux-stable-mirror

[PATCH 1/3] serial: 8250: fix racy uartclk update

by Johan Hovold

Commit 868f3ee6e452 ("serial: 8250: Add 8250 port clock update method") added a hack to support SoCs where the UART reference clock can change behind the back of the driver but failed to add the proper locking. First, make sure to take a reference to the tty struct to avoid dereferencing a NULL pointer if the clock change races with a hangup. Second, the termios semaphore must be held during the update to prevent a racing termios change. Fixes: 868f3ee6e452 ("serial: 8250: Add 8250 port clock update method") Fixes: c8dff3aa8241 ("serial: 8250: Skip uninitialized TTY port baud rate update") Cc: stable(a)vger.kernel.org # 5.9 Cc: Serge Semin <Sergey.Semin(a)baikalelectronics.ru> Signed-off-by: Johan Hovold <johan(a)kernel.org> --- drivers/tty/serial/8250/8250_port.c | 21 +++++++++++++++++---- 1 file changed, 17 insertions(+), 4 deletions(-) diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c index 66374704747e..e4dd82fd7c2a 100644 --- a/drivers/tty/serial/8250/8250_port.c +++ b/drivers/tty/serial/8250/8250_port.c @@ -2696,21 +2696,32 @@ static unsigned int serial8250_get_baud_rate(struct uart_port *port, void serial8250_update_uartclk(struct uart_port *port, unsigned int uartclk) { struct uart_8250_port *up = up_to_u8250p(port); + struct tty_port *tport = &port->state->port; unsigned int baud, quot, frac = 0; struct ktermios *termios; + struct tty_struct *tty; unsigned long flags; - mutex_lock(&port->state->port.mutex); + tty = tty_port_tty_get(tport); + if (!tty) { + mutex_lock(&tport->mutex); + port->uartclk = uartclk; + mutex_unlock(&tport->mutex); + return; + } + + down_write(&tty->termios_rwsem); + mutex_lock(&tport->mutex); if (port->uartclk == uartclk) goto out_lock; port->uartclk = uartclk; - if (!tty_port_initialized(&port->state->port)) + if (!tty_port_initialized(tport)) goto out_lock; - termios = &port->state->port.tty->termios; + termios = &tty->termios; baud = serial8250_get_baud_rate(port, termios, NULL); quot = serial8250_get_divisor(port, baud, &frac); @@ -2727,7 +2738,9 @@ void serial8250_update_uartclk(struct uart_port *port, unsigned int uartclk) serial8250_rpm_put(up); out_lock: - mutex_unlock(&port->state->port.mutex); + mutex_unlock(&tport->mutex); + up_write(&tty->termios_rwsem); + tty_kref_put(tty); } EXPORT_SYMBOL_GPL(serial8250_update_uartclk); -- 2.32.0

3 years, 2 months

2
1
0 0

[PATCH v2 6/6] arm64: dts: imx8mm-kontron: Fix connection type for VSC8531 RGMII PHY

by Frieder Schrempf

From: Frieder Schrempf <frieder.schrempf(a)kontron.de> Previously we falsely relied on the PHY driver to unconditionally enable the internal RX delay. Since the following fix for the PHY driver this is not the case anymore: commit 7b005a1742be ("net: phy: mscc: configure both RX and TX internal delays for RGMII") In order to enable the delay we need to set the connection type to "rgmii-rxid". Without the RX delay the ethernet is not functional at all. Fixes: 8668d8b2e67f ("arm64: dts: Add the Kontron i.MX8M Mini SoMs and baseboards") Cc: stable(a)vger.kernel.org Signed-off-by: Frieder Schrempf <frieder.schrempf(a)kontron.de> --- Changes in v2: * Fix the commit ref in the Fixes tag * Extend the commit message to make clear that ethernet is not working without this fix. --- arch/arm64/boot/dts/freescale/imx8mm-kontron-n801x-s.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-n801x-s.dts b/arch/arm64/boot/dts/freescale/imx8mm-kontron-n801x-s.dts index 14263cd40daf..41ddaf980e14 100644 --- a/arch/arm64/boot/dts/freescale/imx8mm-kontron-n801x-s.dts +++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-n801x-s.dts @@ -113,7 +113,7 @@ &ecspi3 { &fec1 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_enet>; - phy-connection-type = "rgmii"; + phy-connection-type = "rgmii-rxid"; phy-handle = <&ethphy>; status = "okay"; -- 2.33.0

3 years, 2 months

1
0
0 0

[PATCH v2 5/6] arm64: dts: imx8mm-kontron: Fix CAN SPI clock frequency

by Frieder Schrempf

From: Frieder Schrempf <frieder.schrempf(a)kontron.de> The MCP2515 can be used with an SPI clock of up to 10 MHz. Set the limit accordingly to prevent any performance issues caused by the really low clock speed of 100 kHz. This removes the arbitrarily low limit on the SPI frequency, that was caused by a typo in the original dts. Without this change, receiving CAN messages on the board beyond a certain bitrate will cause overrun errors (see 'ip -det -stat link show can0'). With this fix, receiving messages on the bus works without any overrun errors for bitrates up to 1 MBit. Fixes: 8668d8b2e67f ("arm64: dts: Add the Kontron i.MX8M Mini SoMs and baseboards") Cc: stable(a)vger.kernel.org Signed-off-by: Frieder Schrempf <frieder.schrempf(a)kontron.de> --- Changes in v2: * Fix the commit ref in the Fixes tag * Improve commit message --- arch/arm64/boot/dts/freescale/imx8mm-kontron-n801x-s.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-n801x-s.dts b/arch/arm64/boot/dts/freescale/imx8mm-kontron-n801x-s.dts index a192a047f264..14263cd40daf 100644 --- a/arch/arm64/boot/dts/freescale/imx8mm-kontron-n801x-s.dts +++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-n801x-s.dts @@ -97,7 +97,7 @@ can0: can@0 { clocks = <&osc_can>; interrupt-parent = <&gpio4>; interrupts = <28 IRQ_TYPE_EDGE_FALLING>; - spi-max-frequency = <100000>; + spi-max-frequency = <10000000>; vdd-supply = <&reg_vdd_3v3>; xceiver-supply = <&reg_vdd_5v>; }; -- 2.33.0

3 years, 2 months

1
0
0 0

[PATCH v2 4/6] arm64: dts: imx8mm-kontron: Fix polarity of reg_rst_eth2

by Frieder Schrempf

From: Frieder Schrempf <frieder.schrempf(a)kontron.de> The regulator reg_rst_eth2 should keep the reset signal of the USB ethernet adapter deasserted anytime. Fix the polarity and mark it as always-on. Anyway, using the regulator is only a workaround for the missing support of specifying a reset GPIO for USB devices in a generic way. As we don't have a solution for this at the moment, at least fix the current workaround. Fixes: 8668d8b2e67f ("arm64: dts: Add the Kontron i.MX8M Mini SoMs and baseboards") Cc: stable(a)vger.kernel.org Signed-off-by: Frieder Schrempf <frieder.schrempf(a)kontron.de> --- Changes in v2: * Fix the commit ref in the Fixes tag * Improve commit message * Remove useless change of uncontrolled reg_vdd_5v --- arch/arm64/boot/dts/freescale/imx8mm-kontron-n801x-s.dts | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-n801x-s.dts b/arch/arm64/boot/dts/freescale/imx8mm-kontron-n801x-s.dts index 5f6fc4c2c529..a192a047f264 100644 --- a/arch/arm64/boot/dts/freescale/imx8mm-kontron-n801x-s.dts +++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-n801x-s.dts @@ -70,7 +70,9 @@ reg_rst_eth2: regulator-rst-eth2 { regulator-name = "rst-usb-eth2"; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_usb_eth2>; - gpio = <&gpio3 2 GPIO_ACTIVE_LOW>; + gpio = <&gpio3 2 GPIO_ACTIVE_HIGH>; + enable-active-high; + regulator-always-on; }; reg_vdd_5v: regulator-5v { -- 2.33.0

3 years, 2 months

1
0
0 0

[PATCH v2 3/6] arm64: dts: imx8mm-kontron: Set lower limit of VDD_SNVS to 800 mV

by Frieder Schrempf

From: Frieder Schrempf <frieder.schrempf(a)kontron.de> According to the datasheet the typical value for VDD_SNVS should be 800 mV, so let's make sure that this is within the range of the regulator. Fixes: 8668d8b2e67f ("arm64: dts: Add the Kontron i.MX8M Mini SoMs and baseboards") Cc: stable(a)vger.kernel.org Signed-off-by: Frieder Schrempf <frieder.schrempf(a)kontron.de> --- Changes in v2: * Fix the commit ref in the Fixes tag * Only set lower limit of regulator as upper limit matches range im datasheet. --- arch/arm64/boot/dts/freescale/imx8mm-kontron-n801x-som.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-n801x-som.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-kontron-n801x-som.dtsi index 4df45b5e5f6e..1a2a9110e3d1 100644 --- a/arch/arm64/boot/dts/freescale/imx8mm-kontron-n801x-som.dtsi +++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-n801x-som.dtsi @@ -153,7 +153,7 @@ reg_nvcc_snvs: LDO1 { reg_vdd_snvs: LDO2 { regulator-name = "ldo2"; - regulator-min-microvolt = <850000>; + regulator-min-microvolt = <800000>; regulator-max-microvolt = <900000>; regulator-boot-on; regulator-always-on; -- 2.33.0

3 years, 2 months

1
0
0 0

[PATCH v2 2/6] arm64: dts: imx8mm-kontron: Make sure SOC and DRAM supply voltages are correct

by Frieder Schrempf

From: Frieder Schrempf <frieder.schrempf(a)kontron.de> It looks like the voltages for the SOC and DRAM supply weren't properly validated before. The datasheet and uboot-imx code tells us that VDD_SOC should be 800 mV in suspend and 850 mV in run mode. VDD_DRAM should be 950 mV for DDR clock frequencies of up to 1.5 GHz. Let's fix these values to make sure the voltages are within the required range. Fixes: 8668d8b2e67f ("arm64: dts: Add the Kontron i.MX8M Mini SoMs and baseboards") Cc: stable(a)vger.kernel.org Signed-off-by: Frieder Schrempf <frieder.schrempf(a)kontron.de> --- Changes in v2: * Fix the commit ref in the Fixes tag * Improve commit message --- arch/arm64/boot/dts/freescale/imx8mm-kontron-n801x-som.dtsi | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-n801x-som.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-kontron-n801x-som.dtsi index 6eacc32bc95e..4df45b5e5f6e 100644 --- a/arch/arm64/boot/dts/freescale/imx8mm-kontron-n801x-som.dtsi +++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-n801x-som.dtsi @@ -92,10 +92,12 @@ regulators { reg_vdd_soc: BUCK1 { regulator-name = "buck1"; regulator-min-microvolt = <800000>; - regulator-max-microvolt = <900000>; + regulator-max-microvolt = <850000>; regulator-boot-on; regulator-always-on; regulator-ramp-delay = <3125>; + nxp,dvs-run-voltage = <850000>; + nxp,dvs-standby-voltage = <800000>; }; reg_vdd_arm: BUCK2 { @@ -112,7 +114,7 @@ reg_vdd_arm: BUCK2 { reg_vdd_dram: BUCK3 { regulator-name = "buck3"; regulator-min-microvolt = <850000>; - regulator-max-microvolt = <900000>; + regulator-max-microvolt = <950000>; regulator-boot-on; regulator-always-on; }; -- 2.33.0

3 years, 2 months

1
0
0 0

Re: [PATCH] security/landlock: use square brackets around "landlock-ruleset"

by Mickaël Salaün

CCing linux-api and stable to give them a chance to confirm that changing proc symlink content is OK. On 15/10/2021 11:10, Christian Brauner wrote: > On Wed, Oct 13, 2021 at 05:47:53PM +0200, Mickaël Salaün wrote: >> >> On 12/10/2021 23:09, Paul Moore wrote: >>> On Tue, Oct 12, 2021 at 4:38 PM Ondrej Mosnacek <omosnace(a)redhat.com> wrote: >>>> >>>> On Tue, Oct 12, 2021 at 8:12 PM Paul Moore <paul(a)paul-moore.com> wrote: >>>>> On Tue, Oct 12, 2021 at 6:38 AM Christian Brauner >>>>> <christian.brauner(a)ubuntu.com> wrote: >>>>>> On Mon, Oct 11, 2021 at 04:38:55PM +0200, Mickaël Salaün wrote: >>>>>>> On 11/10/2021 15:37, Christian Brauner wrote: >>>>>>>> From: Christian Brauner <christian.brauner(a)ubuntu.com> >>>>>>>> >>>>>>>> Make the name of the anon inode fd "[landlock-ruleset]" instead of >>>>>>>> "landlock-ruleset". This is minor but most anon inode fds already >>>>>>>> carry square brackets around their name: >>>>>>>> >>>>>>>> [eventfd] >>>>>>>> [eventpoll] >>>>>>>> [fanotify] >>>>>>>> [fscontext] >>>>>>>> [io_uring] >>>>>>>> [pidfd] >>>>>>>> [signalfd] >>>>>>>> [timerfd] >>>>>>>> [userfaultfd] >>>>>>>> >>>>>>>> For the sake of consistency lets do the same for the landlock-ruleset anon >>>>>>>> inode fd that comes with landlock. We did the same in >>>>>>>> 1cdc415f1083 ("uapi, fsopen: use square brackets around "fscontext" [ver #2]") >>>>>>>> for the new mount api. >>>>>>> >>>>>>> Before creating "landlock-ruleset" FD, I looked at other anonymous FD >>>>>>> and saw this kind of inconsistency. I don't get why we need to add extra >>>>>>> characters to names, those brackets seem useless. If it should be part >>>>>> >>>>>> Past inconsistency shouldn't justify future inconsistency. If you have a >>>>>> strong opinion about this for landlock I'm not going to push for it. >>>>>> Exchanging more than 2-3 email about something like this seems too much. >>>>> >>>>> [NOTE: adding the SELinux list as well as Chris (SELinux refrence >>>>> policy maintainer) and Petr (Fedora/RHEL SELinux)] >>>>> >>>>> Chris and Petr, do either of you currently have any policy that >>>>> references the "landlock-ruleset" anonymous inode? In other words, >>>>> would adding the brackets around the name cause you any problems? >>>> >>>> AFAIU, the anon_inode transitions (the only mechanism where the "file >>>> name" would be exposed to the policy) are done only for inodes created >>>> by anon_inode_getfd_secure(), which is currently only used by >>>> userfaultfd. So you don't even need to ask that question; at this >>>> point it should be safe to change any of the names except >>>> "[userfaultfd]" as far as SELinux policy is concerned. >>> >>> There is also io_uring if you look at selinux/next. >>> >>> Regardless, thanks, I didn't check to see if landlock was using the >>> new anon inode interface, since both Mickaël and Christian were >>> concerned about breaking SELinux I had assumed they were using it :) >>> >> >> Ok, thanks Paul and Ondrej. >> >> Such anonymous inode names seem to be only exposed to proc for now. >> Let's change this name then. I think it make sense to backport this >> patch down to 5.13 to fix all the inconsistencies. > > Thank you. I do appreciate the point about this being annoying that we > have this inconsistency and it has bothered me too. > > Christian >

3 years, 2 months

1
0
0 0

[PATCH 4/8] arm64: dts: imx8mm-kontron: Fix reg_rst_eth2 and reg_vdd_5v regulators

by Frieder Schrempf

From: Frieder Schrempf <frieder.schrempf(a)kontron.de> The regulator reg_vdd_5v represents the fixed 5V supply on the board which can't be switched off. Mark it as always-on. The regulator reg_rst_eth2 should keep the reset signal of the USB ethernet adapter deassertet anytime. Fix the polarity and mark it as always-on. Fixes: 21c4f45b335f ("arm64: dts: Add the Kontron i.MX8M Mini SoMs and baseboards") Cc: stable(a)vger.kernel.org Signed-off-by: Frieder Schrempf <frieder.schrempf(a)kontron.de> --- arch/arm64/boot/dts/freescale/imx8mm-kontron-n801x-s.dts | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-n801x-s.dts b/arch/arm64/boot/dts/freescale/imx8mm-kontron-n801x-s.dts index 62ba3bd08a0c..f2c8ccefd1bf 100644 --- a/arch/arm64/boot/dts/freescale/imx8mm-kontron-n801x-s.dts +++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-n801x-s.dts @@ -70,7 +70,9 @@ reg_rst_eth2: regulator-rst-eth2 { regulator-name = "rst-usb-eth2"; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_usb_eth2>; - gpio = <&gpio3 2 GPIO_ACTIVE_LOW>; + gpio = <&gpio3 2 GPIO_ACTIVE_HIGH>; + enable-active-high; + regulator-always-on; }; reg_vdd_5v: regulator-5v { @@ -78,6 +80,7 @@ reg_vdd_5v: regulator-5v { regulator-name = "vdd-5v"; regulator-min-microvolt = <5000000>; regulator-max-microvolt = <5000000>; + regulator-always-on; }; }; -- 2.33.0

3 years, 2 months

3
4
0 0

[PATCH 1/8] mtd: rawnand: fsmc: Fix use of SM ORDER

by Miquel Raynal

The introduction of the generic ECC engine API lead to a number of changes in various drivers which broke some of them. Here is a typical example: I expected the SM_ORDER option to be handled by the Hamming ECC engine internals. Problem: the fsmc driver does not instantiate (yet) a real ECC engine object so we had to use a 'bare' ECC helper instead of the shiny rawnand functions. However, when not intializing this engine properly and using the bare helpers, we do not get the SM ORDER feature handled automatically. It looks like this was lost in the process so let's ensure we use the right SM ORDER now. Fixes: ad9ffdce4539 ("mtd: rawnand: fsmc: Fix external use of SW Hamming ECC helper") Cc: stable(a)vger.kernel.org Signed-off-by: Miquel Raynal <miquel.raynal(a)bootlin.com> --- drivers/mtd/nand/raw/fsmc_nand.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/mtd/nand/raw/fsmc_nand.c b/drivers/mtd/nand/raw/fsmc_nand.c index a3e66155ae40..658f0cbe7ce8 100644 --- a/drivers/mtd/nand/raw/fsmc_nand.c +++ b/drivers/mtd/nand/raw/fsmc_nand.c @@ -438,8 +438,10 @@ static int fsmc_correct_ecc1(struct nand_chip *chip, unsigned char *read_ecc, unsigned char *calc_ecc) { + bool sm_order = chip->ecc.options & NAND_ECC_SOFT_HAMMING_SM_ORDER; + return ecc_sw_hamming_correct(buf, read_ecc, calc_ecc, - chip->ecc.size, false); + chip->ecc.size, sm_order); } /* Count the number of 0's in buff upto a max of max_bits */ -- 2.27.0

3 years, 2 months

1
1
0 0

[PATCH 1/9] mtd: rawnand: ams-delta: Keep the driver compatible with on-die ECC engines

by Miquel Raynal

Following the introduction of the generic ECC engine infrastructure, it was necessary to reorganize the code and move the ECC configuration in the ->attach_chip() hook. Failing to do that properly lead to a first series of fixes supposed to stabilize the situation. Unfortunately, this only fixed the use of software ECC engines, preventing any other kind of engine to be used, including on-die ones. It is now time to (finally) fix the situation by ensuring that we still provide a default (eg. software ECC) but will still support different ECC engines such as on-die ECC engines if properly described in the device tree. There are no changes needed on the core side in order to do this, but we just need to leverage the logic there which allows: 1- a subsystem default (set to Host engines in the raw NAND world) 2- a driver specific default (here set to software ECC engines) 3- any type of engine requested by the user (ie. described in the DT) As the raw NAND subsystem has not yet been fully converted to the ECC engine infrastructure, in order to provide a default ECC engine for this driver we need to set chip->ecc.engine_type *before* calling nand_scan(). During the initialization step, the core will consider this entry as the default engine for this driver. This value may of course be overloaded by the user if the usual DT properties are provided. Fixes: 59d93473323a ("mtd: rawnand: ams-delta: Move the ECC initialization to ->attach_chip()") Cc: stable(a)vger.kernel.org Signed-off-by: Miquel Raynal <miquel.raynal(a)bootlin.com> --- drivers/mtd/nand/raw/ams-delta.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/drivers/mtd/nand/raw/ams-delta.c b/drivers/mtd/nand/raw/ams-delta.c index ff1697f899ba..13de39aa3288 100644 --- a/drivers/mtd/nand/raw/ams-delta.c +++ b/drivers/mtd/nand/raw/ams-delta.c @@ -217,9 +217,8 @@ static int gpio_nand_setup_interface(struct nand_chip *this, int csline, static int gpio_nand_attach_chip(struct nand_chip *chip) { - chip->ecc.engine_type = NAND_ECC_ENGINE_TYPE_SOFT; - - if (chip->ecc.algo == NAND_ECC_ALGO_UNKNOWN) + if (chip->ecc.engine_type == NAND_ECC_ENGINE_TYPE_SOFT && + chip->ecc.algo == NAND_ECC_ALGO_UNKNOWN) chip->ecc.algo = NAND_ECC_ALGO_HAMMING; return 0; @@ -370,6 +369,13 @@ static int gpio_nand_probe(struct platform_device *pdev) /* Release write protection */ gpiod_set_value(priv->gpiod_nwp, 0); + /* + * This driver assumes that the default ECC engine should be TYPE_SOFT. + * Set ->engine_type before registering the NAND devices in order to + * provide a driver specific default value. + */ + this->ecc.engine_type = NAND_ECC_ENGINE_TYPE_SOFT; + /* Scan to find existence of the device */ err = nand_scan(this, 1); if (err) -- 2.27.0

3 years, 2 months

1
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror October 2021