January 2024 - Linux-stable-mirror

[PATCH] KVM: x86/pmu: fix masking logic for MSR_CORE_PERF_GLOBAL_CTRL

by Paolo Bonzini

When commit c59a1f106f5c ("KVM: x86/pmu: Add IA32_PEBS_ENABLE MSR emulation for extended PEBS") switched the initialization of cpuc->guest_switch_msrs to use compound literals, it screwed up the boolean logic: + u64 pebs_mask = cpuc->pebs_enabled & x86_pmu.pebs_capable; ... - arr[0].guest = intel_ctrl & ~cpuc->intel_ctrl_host_mask; - arr[0].guest &= ~(cpuc->pebs_enabled & x86_pmu.pebs_capable); + .guest = intel_ctrl & (~cpuc->intel_ctrl_host_mask | ~pebs_mask), Before the patch, the value of arr[0].guest would have been intel_ctrl & ~cpuc->intel_ctrl_host_mask & ~pebs_mask. The intent is to always treat PEBS events as host-only because, while the guest runs, there is no way to tell the processor about the virtual address where to put PEBS records intended for the host. Unfortunately, the new expression can be expanded to (intel_ctrl & ~cpuc->intel_ctrl_host_mask) | (intel_ctrl & ~pebs_mask) which makes no sense; it includes any bit that isn't *both* marked as exclude_guest and using PEBS. So, reinstate the old logic. Another way to write it could be "intel_ctrl & ~(cpuc->intel_ctrl_host_mask | pebs_mask)", presumably the intention of the author of the faulty. However, I personally find the repeated application of A AND NOT B to be a bit more readable. This shows up as guest failures when running concurrent long-running perf workloads on the host, and was reported to happen with rcutorture. All guests on a given host would die simultaneously with something like an instruction fault or a segmentation violation. Reported-by: Paul E. McKenney <paulmck(a)kernel.org> Analyzed-by: Sean Christopherson <seanjc(a)google.com> Tested-by: Paul E. McKenney <paulmck(a)kernel.org> Cc: stable(a)vger.kernel.org Fixes: c59a1f106f5c ("KVM: x86/pmu: Add IA32_PEBS_ENABLE MSR emulation for extended PEBS") Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> --- arch/x86/events/intel/core.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c index ce1c777227b4..0f2786d4e405 100644 --- a/arch/x86/events/intel/core.c +++ b/arch/x86/events/intel/core.c @@ -4051,12 +4051,17 @@ static struct perf_guest_switch_msr *intel_guest_get_msrs(int *nr, void *data) u64 pebs_mask = cpuc->pebs_enabled & x86_pmu.pebs_capable; int global_ctrl, pebs_enable; + /* + * In addition to obeying exclude_guest/exclude_host, remove bits being + * used for PEBS when running a guest, because PEBS writes to virtual + * addresses (not physical addresses). + */ *nr = 0; global_ctrl = (*nr)++; arr[global_ctrl] = (struct perf_guest_switch_msr){ .msr = MSR_CORE_PERF_GLOBAL_CTRL, .host = intel_ctrl & ~cpuc->intel_ctrl_guest_mask, - .guest = intel_ctrl & (~cpuc->intel_ctrl_host_mask | ~pebs_mask), + .guest = intel_ctrl & ~cpuc->intel_ctrl_host_mask & ~pebs_mask, }; if (!x86_pmu.pebs) -- 2.43.0

1 year, 6 months

3
3
0 0

Re: [PATCH v3] rootfs: Fix support for rootfstype= when root= is given

by Askar Safin

On Sun, Nov 19, 2023 at 08:12:48PM -0500, Stefan Berger wrote: > Documentation/filesystems/ramfs-rootfs-initramfs.rst states: > > If CONFIG_TMPFS is enabled, rootfs will use tmpfs instead of ramfs by > default. To force ramfs, add "rootfstype=ramfs" to the kernel command > line. > > This currently does not work when root= is provided since then > saved_root_name contains a string and rootfstype= is ignored. Therefore, > ramfs is currently always chosen when root= is provided. Maybe it is a good idea to just fully remove ramfs? initramfs will always be tmpfs. And tmpfs will always be enabled. As well as I understand, ramfs was originally introduced, because tmpfs seemed too big. So, it seemed to be a good idea to have small fs (ramfs), which is always enabled. I just did an experiment. I compiled the kernel with a very small config. And without TMPFS and SHMEM. I got 1059440 bytes image. Then I enabled TMPFS and SHMEM, and I got 1072976 bytes. So tmpfs adds 13536 bytes, i. e. 14k, which is a very small amount. It adds 1.3 % to the kernel even with very small config. So I propose to remove ramfs and always enable tmpfs. This will decrease complexity. Here are my configs (x86_64). Just enough to run busybox in "qemu -serial stdio" make KCONFIG_ALLCONFIG="$FILE" allnoconfig CONFIG_64BIT=y CONFIG_PRINTK=y CONFIG_SERIAL_8250=y CONFIG_TTY=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_BLK_DEV_INITRD=y CONFIG_RD_GZIP=y CONFIG_BINFMT_ELF=y CONFIG_EMBEDDED=y CONFIG_EXPERT=y CONFIG_TMPFS=n # Try to change this to "y" CONFIG_SHMEM=n # Try to change this to "y" Here is full docker reproducer: # Reproducible # 20230227 = 20230227T000000Z = 20230226T090712Z FROM debian:sid-20230227 ENV LC_ALL C.UTF-8 RUN sed -i 's~^URIs:.*$~URIs: http://snapshot.debian.org/archive/debian/20230226T090712Z~' /etc/apt/sources.list.d/debian.sources RUN echo 'Acquire::Check-Valid-Until "false";' > /etc/apt/apt.conf.d/02acquire-check-valid-until RUN apt-get update && apt-get install -y apt-utils whiptail RUN apt-get update && apt-get install -y busybox-static qemu-system-x86 make gcc git flex bison bc libelf-dev less nano cpio RUN git clone --depth=1 -b v6.2 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git RUN : > /.config # See Linux f8f0d06438e5c810d1e13b5f8c2fed501fe36e9c RUN echo 'CONFIG_64BIT=y' >> /.config RUN echo 'CONFIG_PRINTK=y' >> /.config RUN echo 'CONFIG_SERIAL_8250=y' >> /.config RUN echo 'CONFIG_TTY=y' >> /.config RUN echo 'CONFIG_SERIAL_8250_CONSOLE=y' >> /.config RUN echo 'CONFIG_BLK_DEV_INITRD=y' >> /.config RUN echo 'CONFIG_RD_GZIP=y' >> /.config RUN echo 'CONFIG_BINFMT_ELF=y' >> /.config RUN echo 'CONFIG_EMBEDDED=y' >> /.config RUN echo 'CONFIG_EXPERT=y' >> /.config RUN echo 'CONFIG_TMPFS=y' >> /.config # try "n" RUN echo 'CONFIG_SHMEM=y' >> /.config # try "n" RUN cd linux && make KCONFIG_ALLCONFIG=/.config allnoconfig RUN cd linux && make -j4 RUN mkdir /initramfs && cp /bin/busybox /initramfs && cd /initramfs && ln -s busybox sh && find . | cpio --create --format=newc --quiet | gzip > /initramfs.cpio.gz RUN echo "qemu-system-x86_64 -M microvm -m 64M -serial stdio -display none -kernel /linux/arch/x86/boot/bzImage -initrd /initramfs.cpio.gz -append 'quiet console=ttyS0 earlyprintk=ttyS0 rdinit=/sh' -nodefaults -no-user-config" > /root/.bash_history -- Askar Safin

1 year, 6 months

3
16
0 0

patch "usb: typec: class: fix typec_altmode_put_partner to put plugs" added to usb-testing

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: typec: class: fix typec_altmode_put_partner to put plugs to my usb git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git in the usb-testing branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will be merged to the usb-next branch sometime soon, after it passes testing, and the merge window is open. If you have any questions about this process, please let me know. From 5962ded777d689cd8bf04454273e32228d7fb71f Mon Sep 17 00:00:00 2001 From: RD Babiera <rdbabiera(a)google.com> Date: Wed, 3 Jan 2024 18:17:55 +0000 Subject: usb: typec: class: fix typec_altmode_put_partner to put plugs When typec_altmode_put_partner is called by a plug altmode upon release, the port altmode the plug belongs to will not remove its reference to the plug. The check to see if the altmode being released is a plug evaluates against the released altmode's partner instead of the calling altmode, so change adev in typec_altmode_put_partner to properly refer to the altmode being released. Because typec_altmode_set_partner calls get_device() on the port altmode, add partner_adev that points to the port altmode in typec_put_partner to call put_device() on. typec_altmode_set_partner is not called for port altmodes, so add a check in typec_altmode_release to prevent typec_altmode_put_partner() calls on port altmode release. Fixes: 8a37d87d72f0 ("usb: typec: Bus type for alternate modes") Cc: <stable(a)vger.kernel.org> Co-developed-by: Christian A. Ehrhardt <lk(a)c--e.de> Signed-off-by: Christian A. Ehrhardt <lk(a)c--e.de> Signed-off-by: RD Babiera <rdbabiera(a)google.com> Tested-by: Christian A. Ehrhardt <lk(a)c--e.de> Acked-by: Heikki Krogerus <heikki.krogerus(a)linux.intel.com> Link: https://lore.kernel.org/r/20240103181754.2492492-2-rdbabiera@google.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/typec/class.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/usb/typec/class.c b/drivers/usb/typec/class.c index 4d11f2b536fa..015aa9253353 100644 --- a/drivers/usb/typec/class.c +++ b/drivers/usb/typec/class.c @@ -263,11 +263,13 @@ static void typec_altmode_put_partner(struct altmode *altmode) { struct altmode *partner = altmode->partner; struct typec_altmode *adev; + struct typec_altmode *partner_adev; if (!partner) return; - adev = &partner->adev; + adev = &altmode->adev; + partner_adev = &partner->adev; if (is_typec_plug(adev->dev.parent)) { struct typec_plug *plug = to_typec_plug(adev->dev.parent); @@ -276,7 +278,7 @@ static void typec_altmode_put_partner(struct altmode *altmode) } else { partner->partner = NULL; } - put_device(&adev->dev); + put_device(&partner_adev->dev); } /** @@ -497,7 +499,8 @@ static void typec_altmode_release(struct device *dev) { struct altmode *alt = to_altmode(to_typec_altmode(dev)); - typec_altmode_put_partner(alt); + if (!is_typec_port(dev->parent)) + typec_altmode_put_partner(alt); altmode_id_remove(alt->adev.dev.parent, alt->id); kfree(alt); -- 2.43.0

1 year, 6 months

1
0
0 0

patch "serial: sc16is7xx: remove obsolete loop in sc16is7xx_port_irq()" added to tty-testing

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled serial: sc16is7xx: remove obsolete loop in sc16is7xx_port_irq() to my tty git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git in the tty-testing branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will be merged to the tty-next branch sometime soon, after it passes testing, and the merge window is open. If you have any questions about this process, please let me know. From ed647256e8f226241ecff7baaecdb8632ffc7ec1 Mon Sep 17 00:00:00 2001 From: Hugo Villeneuve <hvilleneuve(a)dimonoff.com> Date: Thu, 21 Dec 2023 18:18:11 -0500 Subject: serial: sc16is7xx: remove obsolete loop in sc16is7xx_port_irq() Commit 834449872105 ("sc16is7xx: Fix for multi-channel stall") changed sc16is7xx_port_irq() from looping multiple times when there was still interrupts to serve. It simply changed the do {} while(1) loop to a do {} while(0) loop, which makes the loop itself now obsolete. Clean the code by removing this obsolete do {} while(0) loop. Fixes: 834449872105 ("sc16is7xx: Fix for multi-channel stall") Cc: <stable(a)vger.kernel.org> Suggested-by: Andy Shevchenko <andy.shevchenko(a)gmail.com> Signed-off-by: Hugo Villeneuve <hvilleneuve(a)dimonoff.com> Link: https://lore.kernel.org/r/20231221231823.2327894-5-hugo@hugovil.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/tty/serial/sc16is7xx.c | 81 ++++++++++++++++------------------ 1 file changed, 39 insertions(+), 42 deletions(-) diff --git a/drivers/tty/serial/sc16is7xx.c b/drivers/tty/serial/sc16is7xx.c index ced2446909a2..44a11c89c949 100644 --- a/drivers/tty/serial/sc16is7xx.c +++ b/drivers/tty/serial/sc16is7xx.c @@ -725,58 +725,55 @@ static void sc16is7xx_update_mlines(struct sc16is7xx_one *one) static bool sc16is7xx_port_irq(struct sc16is7xx_port *s, int portno) { bool rc = true; + unsigned int iir, rxlen; struct uart_port *port = &s->p[portno].port; struct sc16is7xx_one *one = to_sc16is7xx_one(port, port); mutex_lock(&one->efr_lock); - do { - unsigned int iir, rxlen; + iir = sc16is7xx_port_read(port, SC16IS7XX_IIR_REG); + if (iir & SC16IS7XX_IIR_NO_INT_BIT) { + rc = false; + goto out_port_irq; + } - iir = sc16is7xx_port_read(port, SC16IS7XX_IIR_REG); - if (iir & SC16IS7XX_IIR_NO_INT_BIT) { - rc = false; - goto out_port_irq; - } + iir &= SC16IS7XX_IIR_ID_MASK; - iir &= SC16IS7XX_IIR_ID_MASK; + switch (iir) { + case SC16IS7XX_IIR_RDI_SRC: + case SC16IS7XX_IIR_RLSE_SRC: + case SC16IS7XX_IIR_RTOI_SRC: + case SC16IS7XX_IIR_XOFFI_SRC: + rxlen = sc16is7xx_port_read(port, SC16IS7XX_RXLVL_REG); - switch (iir) { - case SC16IS7XX_IIR_RDI_SRC: - case SC16IS7XX_IIR_RLSE_SRC: - case SC16IS7XX_IIR_RTOI_SRC: - case SC16IS7XX_IIR_XOFFI_SRC: - rxlen = sc16is7xx_port_read(port, SC16IS7XX_RXLVL_REG); + /* + * There is a silicon bug that makes the chip report a + * time-out interrupt but no data in the FIFO. This is + * described in errata section 18.1.4. + * + * When this happens, read one byte from the FIFO to + * clear the interrupt. + */ + if (iir == SC16IS7XX_IIR_RTOI_SRC && !rxlen) + rxlen = 1; - /* - * There is a silicon bug that makes the chip report a - * time-out interrupt but no data in the FIFO. This is - * described in errata section 18.1.4. - * - * When this happens, read one byte from the FIFO to - * clear the interrupt. - */ - if (iir == SC16IS7XX_IIR_RTOI_SRC && !rxlen) - rxlen = 1; - - if (rxlen) - sc16is7xx_handle_rx(port, rxlen, iir); - break; + if (rxlen) + sc16is7xx_handle_rx(port, rxlen, iir); + break; /* CTSRTS interrupt comes only when CTS goes inactive */ - case SC16IS7XX_IIR_CTSRTS_SRC: - case SC16IS7XX_IIR_MSI_SRC: - sc16is7xx_update_mlines(one); - break; - case SC16IS7XX_IIR_THRI_SRC: - sc16is7xx_handle_tx(port); - break; - default: - dev_err_ratelimited(port->dev, - "ttySC%i: Unexpected interrupt: %x", - port->line, iir); - break; - } - } while (0); + case SC16IS7XX_IIR_CTSRTS_SRC: + case SC16IS7XX_IIR_MSI_SRC: + sc16is7xx_update_mlines(one); + break; + case SC16IS7XX_IIR_THRI_SRC: + sc16is7xx_handle_tx(port); + break; + default: + dev_err_ratelimited(port->dev, + "ttySC%i: Unexpected interrupt: %x", + port->line, iir); + break; + } out_port_irq: mutex_unlock(&one->efr_lock); -- 2.43.0

1 year, 6 months

1
0
0 0

patch "serial: sc16is7xx: improve do/while loop in sc16is7xx_irq()" added to tty-testing

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled serial: sc16is7xx: improve do/while loop in sc16is7xx_irq() to my tty git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git in the tty-testing branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will be merged to the tty-next branch sometime soon, after it passes testing, and the merge window is open. If you have any questions about this process, please let me know. From d5078509c8b06c5c472a60232815e41af81c6446 Mon Sep 17 00:00:00 2001 From: Hugo Villeneuve <hvilleneuve(a)dimonoff.com> Date: Thu, 21 Dec 2023 18:18:12 -0500 Subject: serial: sc16is7xx: improve do/while loop in sc16is7xx_irq() Simplify and improve readability by replacing while(1) loop with do {} while, and by using the keep_polling variable as the exit condition, making it more explicit. Fixes: 834449872105 ("sc16is7xx: Fix for multi-channel stall") Cc: <stable(a)vger.kernel.org> Suggested-by: Andy Shevchenko <andy.shevchenko(a)gmail.com> Signed-off-by: Hugo Villeneuve <hvilleneuve(a)dimonoff.com> Link: https://lore.kernel.org/r/20231221231823.2327894-6-hugo@hugovil.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/tty/serial/sc16is7xx.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/drivers/tty/serial/sc16is7xx.c b/drivers/tty/serial/sc16is7xx.c index 44a11c89c949..8d257208cbf3 100644 --- a/drivers/tty/serial/sc16is7xx.c +++ b/drivers/tty/serial/sc16is7xx.c @@ -783,17 +783,18 @@ static bool sc16is7xx_port_irq(struct sc16is7xx_port *s, int portno) static irqreturn_t sc16is7xx_irq(int irq, void *dev_id) { + bool keep_polling; + struct sc16is7xx_port *s = (struct sc16is7xx_port *)dev_id; - while (1) { - bool keep_polling = false; + do { int i; + keep_polling = false; + for (i = 0; i < s->devtype->nr_uart; ++i) keep_polling |= sc16is7xx_port_irq(s, i); - if (!keep_polling) - break; - } + } while (keep_polling); return IRQ_HANDLED; } -- 2.43.0

1 year, 6 months

1
0
0 0

patch "serial: sc16is7xx: set safe default SPI clock frequency" added to tty-testing

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled serial: sc16is7xx: set safe default SPI clock frequency to my tty git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git in the tty-testing branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will be merged to the tty-next branch sometime soon, after it passes testing, and the merge window is open. If you have any questions about this process, please let me know. From 3ef79cd1412236d884ab0c46b4d1921380807b48 Mon Sep 17 00:00:00 2001 From: Hugo Villeneuve <hvilleneuve(a)dimonoff.com> Date: Thu, 21 Dec 2023 18:18:10 -0500 Subject: serial: sc16is7xx: set safe default SPI clock frequency 15 MHz is supported only by 76x variants. If the SPI clock frequency is not specified, use a safe default clock value of 4 MHz that is supported by all variants. Also use HZ_PER_MHZ macro to improve readability. Fixes: 2c837a8a8f9f ("sc16is7xx: spi interface is added") Cc: <stable(a)vger.kernel.org> Signed-off-by: Hugo Villeneuve <hvilleneuve(a)dimonoff.com> Link: https://lore.kernel.org/r/20231221231823.2327894-4-hugo@hugovil.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/tty/serial/sc16is7xx.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/tty/serial/sc16is7xx.c b/drivers/tty/serial/sc16is7xx.c index 798fa115b28a..ced2446909a2 100644 --- a/drivers/tty/serial/sc16is7xx.c +++ b/drivers/tty/serial/sc16is7xx.c @@ -24,6 +24,7 @@ #include <linux/tty_flip.h> #include <linux/spi/spi.h> #include <linux/uaccess.h> +#include <linux/units.h> #include <uapi/linux/sched/types.h> #define SC16IS7XX_NAME "sc16is7xx" @@ -1738,7 +1739,7 @@ static int sc16is7xx_spi_probe(struct spi_device *spi) return dev_err_probe(&spi->dev, -EINVAL, "Unsupported SPI mode\n"); spi->mode = spi->mode ? : SPI_MODE_0; - spi->max_speed_hz = spi->max_speed_hz ? : 15000000; + spi->max_speed_hz = spi->max_speed_hz ? : 4 * HZ_PER_MHZ; ret = spi_setup(spi); if (ret) return ret; -- 2.43.0

1 year, 6 months

1
0
0 0

patch "serial: sc16is7xx: add check for unsupported SPI modes during probe" added to tty-testing

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled serial: sc16is7xx: add check for unsupported SPI modes during probe to my tty git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git in the tty-testing branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will be merged to the tty-next branch sometime soon, after it passes testing, and the merge window is open. If you have any questions about this process, please let me know. From 6d710b769c1f5f0d55c9ad9bb49b7dce009ec103 Mon Sep 17 00:00:00 2001 From: Hugo Villeneuve <hvilleneuve(a)dimonoff.com> Date: Thu, 21 Dec 2023 18:18:09 -0500 Subject: serial: sc16is7xx: add check for unsupported SPI modes during probe The original comment is confusing because it implies that variants other than the SC16IS762 supports other SPI modes beside SPI_MODE_0. Extract from datasheet: The SC16IS762 differs from the SC16IS752 in that it supports SPI clock speeds up to 15 Mbit/s instead of the 4 Mbit/s supported by the SC16IS752... In all other aspects, the SC16IS762 is functionally and electrically the same as the SC16IS752. The same is also true of the SC16IS760 variant versus the SC16IS740 and SC16IS750 variants. For all variants, only SPI mode 0 is supported. Change comment and abort probing if the specified SPI mode is not SPI_MODE_0. Fixes: 2c837a8a8f9f ("sc16is7xx: spi interface is added") Cc: <stable(a)vger.kernel.org> Signed-off-by: Hugo Villeneuve <hvilleneuve(a)dimonoff.com> Link: https://lore.kernel.org/r/20231221231823.2327894-3-hugo@hugovil.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/tty/serial/sc16is7xx.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/tty/serial/sc16is7xx.c b/drivers/tty/serial/sc16is7xx.c index 17b90f971f96..798fa115b28a 100644 --- a/drivers/tty/serial/sc16is7xx.c +++ b/drivers/tty/serial/sc16is7xx.c @@ -1733,7 +1733,10 @@ static int sc16is7xx_spi_probe(struct spi_device *spi) /* Setup SPI bus */ spi->bits_per_word = 8; - /* only supports mode 0 on SC16IS762 */ + /* For all variants, only mode 0 is supported */ + if ((spi->mode & SPI_MODE_X_MASK) != SPI_MODE_0) + return dev_err_probe(&spi->dev, -EINVAL, "Unsupported SPI mode\n"); + spi->mode = spi->mode ? : SPI_MODE_0; spi->max_speed_hz = spi->max_speed_hz ? : 15000000; ret = spi_setup(spi); -- 2.43.0

1 year, 6 months

1
0
0 0

patch "serial: sc16is7xx: fix invalid sc16is7xx_lines bitfield in case of" added to tty-testing

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled serial: sc16is7xx: fix invalid sc16is7xx_lines bitfield in case of to my tty git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git in the tty-testing branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will be merged to the tty-next branch sometime soon, after it passes testing, and the merge window is open. If you have any questions about this process, please let me know. From 8a1060ce974919f2a79807527ad82ac39336eda2 Mon Sep 17 00:00:00 2001 From: Hugo Villeneuve <hvilleneuve(a)dimonoff.com> Date: Thu, 21 Dec 2023 18:18:08 -0500 Subject: serial: sc16is7xx: fix invalid sc16is7xx_lines bitfield in case of probe error If an error occurs during probing, the sc16is7xx_lines bitfield may be left in a state that doesn't represent the correct state of lines allocation. For example, in a system with two SC16 devices, if an error occurs only during probing of channel (port) B of the second device, sc16is7xx_lines final state will be 00001011b instead of the expected 00000011b. This is caused in part because of the "i--" in the for/loop located in the out_ports: error path. Fix this by checking the return value of uart_add_one_port() and set line allocation bit only if this was successful. This allows the refactor of the obfuscated for(i--...) loop in the error path, and properly call uart_remove_one_port() only when needed, and properly unset line allocation bits. Also use same mechanism in remove() when calling uart_remove_one_port(). Fixes: c64349722d14 ("sc16is7xx: support multiple devices") Cc: <stable(a)vger.kernel.org> Cc: Yury Norov <yury.norov(a)gmail.com> Signed-off-by: Hugo Villeneuve <hvilleneuve(a)dimonoff.com> Link: https://lore.kernel.org/r/20231221231823.2327894-2-hugo@hugovil.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/tty/serial/sc16is7xx.c | 44 ++++++++++++++-------------------- 1 file changed, 18 insertions(+), 26 deletions(-) diff --git a/drivers/tty/serial/sc16is7xx.c b/drivers/tty/serial/sc16is7xx.c index e40e4a99277e..17b90f971f96 100644 --- a/drivers/tty/serial/sc16is7xx.c +++ b/drivers/tty/serial/sc16is7xx.c @@ -407,19 +407,6 @@ static void sc16is7xx_port_update(struct uart_port *port, u8 reg, regmap_update_bits(one->regmap, reg, mask, val); } -static int sc16is7xx_alloc_line(void) -{ - int i; - - BUILD_BUG_ON(SC16IS7XX_MAX_DEVS > BITS_PER_LONG); - - for (i = 0; i < SC16IS7XX_MAX_DEVS; i++) - if (!test_and_set_bit(i, &sc16is7xx_lines)) - break; - - return i; -} - static void sc16is7xx_power(struct uart_port *port, int on) { sc16is7xx_port_update(port, SC16IS7XX_IER_REG, @@ -1550,6 +1537,13 @@ static int sc16is7xx_probe(struct device *dev, SC16IS7XX_IOCONTROL_SRESET_BIT); for (i = 0; i < devtype->nr_uart; ++i) { + s->p[i].port.line = find_first_zero_bit(&sc16is7xx_lines, + SC16IS7XX_MAX_DEVS); + if (s->p[i].port.line >= SC16IS7XX_MAX_DEVS) { + ret = -ERANGE; + goto out_ports; + } + /* Initialize port data */ s->p[i].port.dev = dev; s->p[i].port.irq = irq; @@ -1569,14 +1563,8 @@ static int sc16is7xx_probe(struct device *dev, s->p[i].port.rs485_supported = sc16is7xx_rs485_supported; s->p[i].port.ops = &sc16is7xx_ops; s->p[i].old_mctrl = 0; - s->p[i].port.line = sc16is7xx_alloc_line(); s->p[i].regmap = regmaps[i]; - if (s->p[i].port.line >= SC16IS7XX_MAX_DEVS) { - ret = -ENOMEM; - goto out_ports; - } - mutex_init(&s->p[i].efr_lock); ret = uart_get_rs485_mode(&s->p[i].port); @@ -1594,8 +1582,13 @@ static int sc16is7xx_probe(struct device *dev, kthread_init_work(&s->p[i].tx_work, sc16is7xx_tx_proc); kthread_init_work(&s->p[i].reg_work, sc16is7xx_reg_proc); kthread_init_delayed_work(&s->p[i].ms_work, sc16is7xx_ms_proc); + /* Register port */ - uart_add_one_port(&sc16is7xx_uart, &s->p[i].port); + ret = uart_add_one_port(&sc16is7xx_uart, &s->p[i].port); + if (ret) + goto out_ports; + + set_bit(s->p[i].port.line, &sc16is7xx_lines); /* Enable EFR */ sc16is7xx_port_write(&s->p[i].port, SC16IS7XX_LCR_REG, @@ -1653,10 +1646,9 @@ static int sc16is7xx_probe(struct device *dev, #endif out_ports: - for (i--; i >= 0; i--) { - uart_remove_one_port(&sc16is7xx_uart, &s->p[i].port); - clear_bit(s->p[i].port.line, &sc16is7xx_lines); - } + for (i = 0; i < devtype->nr_uart; i++) + if (test_and_clear_bit(s->p[i].port.line, &sc16is7xx_lines)) + uart_remove_one_port(&sc16is7xx_uart, &s->p[i].port); kthread_stop(s->kworker_task); @@ -1678,8 +1670,8 @@ static void sc16is7xx_remove(struct device *dev) for (i = 0; i < s->devtype->nr_uart; i++) { kthread_cancel_delayed_work_sync(&s->p[i].ms_work); - uart_remove_one_port(&sc16is7xx_uart, &s->p[i].port); - clear_bit(s->p[i].port.line, &sc16is7xx_lines); + if (test_and_clear_bit(s->p[i].port.line, &sc16is7xx_lines)) + uart_remove_one_port(&sc16is7xx_uart, &s->p[i].port); sc16is7xx_power(&s->p[i].port, 0); } -- 2.43.0

1 year, 6 months

1
0
0 0

patch "serial: 8250_exar: Set missing rs485_supported flag" added to tty-testing

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled serial: 8250_exar: Set missing rs485_supported flag to my tty git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git in the tty-testing branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will be merged to the tty-next branch sometime soon, after it passes testing, and the merge window is open. If you have any questions about this process, please let me know. From 0c2a5f471ce58bca8f8ab5fcb911aff91eaaa5eb Mon Sep 17 00:00:00 2001 From: Lino Sanfilippo <l.sanfilippo(a)kunbus.com> Date: Wed, 3 Jan 2024 07:18:18 +0100 Subject: serial: 8250_exar: Set missing rs485_supported flag MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The UART supports an auto-RTS mode in which the RTS pin is automatically activated during transmission. So mark this mode as being supported even if RTS is not controlled by the driver but the UART. Also the serial core expects now at least one of both modes rts-on-send or rts-after-send to be supported. This is since during sanitization unsupported flags are deleted from a RS485 configuration set by userspace. However if the configuration ends up with both flags unset, the core prints a warning since it considers such a configuration invalid (see uart_sanitize_serial_rs485()). Cc: <stable(a)vger.kernel.org> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen(a)linux.intel.com> Signed-off-by: Lino Sanfilippo <l.sanfilippo(a)kunbus.com> Link: https://lore.kernel.org/r/20240103061818.564-8-l.sanfilippo@kunbus.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/tty/serial/8250/8250_exar.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/tty/serial/8250/8250_exar.c b/drivers/tty/serial/8250/8250_exar.c index 6085d356ad86..23366f868ae3 100644 --- a/drivers/tty/serial/8250/8250_exar.c +++ b/drivers/tty/serial/8250/8250_exar.c @@ -480,7 +480,7 @@ static int sealevel_rs485_config(struct uart_port *port, struct ktermios *termio } static const struct serial_rs485 generic_rs485_supported = { - .flags = SER_RS485_ENABLED, + .flags = SER_RS485_ENABLED | SER_RS485_RTS_ON_SEND, }; static const struct exar8250_platform exar8250_default_platform = { @@ -524,7 +524,8 @@ static int iot2040_rs485_config(struct uart_port *port, struct ktermios *termios } static const struct serial_rs485 iot2040_rs485_supported = { - .flags = SER_RS485_ENABLED | SER_RS485_RX_DURING_TX | SER_RS485_TERMINATE_BUS, + .flags = SER_RS485_ENABLED | SER_RS485_RTS_ON_SEND | + SER_RS485_RX_DURING_TX | SER_RS485_TERMINATE_BUS, }; static const struct property_entry iot2040_gpio_properties[] = { -- 2.43.0

1 year, 6 months

1
0
0 0

patch "serial: omap: do not override settings for RS485 support" added to tty-testing

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled serial: omap: do not override settings for RS485 support to my tty git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git in the tty-testing branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will be merged to the tty-next branch sometime soon, after it passes testing, and the merge window is open. If you have any questions about this process, please let me know. From 51f93776b84dee23e44a7be880736669a01cec2b Mon Sep 17 00:00:00 2001 From: Lino Sanfilippo <l.sanfilippo(a)kunbus.com> Date: Wed, 3 Jan 2024 07:18:17 +0100 Subject: serial: omap: do not override settings for RS485 support MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The drivers RS485 support is deactivated if there is no RTS GPIO available. This is done by nullifying the ports rs485_supported struct. After that however the settings in serial_omap_rs485_supported are assigned to the same structure unconditionally, which results in an unintended reactivation of RS485 support. Fix this by moving the assignment to the beginning of serial_omap_probe_rs485() and thus before uart_get_rs485_mode() gets called. Also replace the assignment of rs485_config() to have the complete RS485 setup in one function. Fixes: e2752ae3cfc9 ("serial: omap: Disallow RS-485 if rts-gpio is not specified") Cc: <stable(a)vger.kernel.org> Signed-off-by: Lino Sanfilippo <l.sanfilippo(a)kunbus.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen(a)linux.intel.com> Link: https://lore.kernel.org/r/20240103061818.564-7-l.sanfilippo@kunbus.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/tty/serial/omap-serial.c | 27 ++++++++++++++------------- 1 file changed, 14 insertions(+), 13 deletions(-) diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c index 730755621879..f5a0b401af63 100644 --- a/drivers/tty/serial/omap-serial.c +++ b/drivers/tty/serial/omap-serial.c @@ -1483,6 +1483,13 @@ static struct omap_uart_port_info *of_get_uart_port_info(struct device *dev) return omap_up_info; } +static const struct serial_rs485 serial_omap_rs485_supported = { + .flags = SER_RS485_ENABLED | SER_RS485_RTS_ON_SEND | SER_RS485_RTS_AFTER_SEND | + SER_RS485_RX_DURING_TX, + .delay_rts_before_send = 1, + .delay_rts_after_send = 1, +}; + static int serial_omap_probe_rs485(struct uart_omap_port *up, struct device *dev) { @@ -1497,6 +1504,9 @@ static int serial_omap_probe_rs485(struct uart_omap_port *up, if (!np) return 0; + up->port.rs485_config = serial_omap_config_rs485; + up->port.rs485_supported = serial_omap_rs485_supported; + ret = uart_get_rs485_mode(&up->port); if (ret) return ret; @@ -1531,13 +1541,6 @@ static int serial_omap_probe_rs485(struct uart_omap_port *up, return 0; } -static const struct serial_rs485 serial_omap_rs485_supported = { - .flags = SER_RS485_ENABLED | SER_RS485_RTS_ON_SEND | SER_RS485_RTS_AFTER_SEND | - SER_RS485_RX_DURING_TX, - .delay_rts_before_send = 1, - .delay_rts_after_send = 1, -}; - static int serial_omap_probe(struct platform_device *pdev) { struct omap_uart_port_info *omap_up_info = dev_get_platdata(&pdev->dev); @@ -1604,17 +1607,11 @@ static int serial_omap_probe(struct platform_device *pdev) dev_info(up->port.dev, "no wakeirq for uart%d\n", up->port.line); - ret = serial_omap_probe_rs485(up, &pdev->dev); - if (ret < 0) - goto err_rs485; - sprintf(up->name, "OMAP UART%d", up->port.line); up->port.mapbase = mem->start; up->port.membase = base; up->port.flags = omap_up_info->flags; up->port.uartclk = omap_up_info->uartclk; - up->port.rs485_config = serial_omap_config_rs485; - up->port.rs485_supported = serial_omap_rs485_supported; if (!up->port.uartclk) { up->port.uartclk = DEFAULT_CLK_SPEED; dev_warn(&pdev->dev, @@ -1622,6 +1619,10 @@ static int serial_omap_probe(struct platform_device *pdev) DEFAULT_CLK_SPEED); } + ret = serial_omap_probe_rs485(up, &pdev->dev); + if (ret < 0) + goto err_rs485; + up->latency = PM_QOS_CPU_LATENCY_DEFAULT_VALUE; up->calc_latency = PM_QOS_CPU_LATENCY_DEFAULT_VALUE; cpu_latency_qos_add_request(&up->pm_qos_request, up->latency); -- 2.43.0

1 year, 6 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror January 2024