--- /dev/null
+From f71f6ff8c1f682a1cae4e8d7bdeed9d7f76b8f75 Mon Sep 17 00:00:00 2001
+From: Tony Lindgren <tony@atomide.com>
+Date: Fri, 24 Nov 2023 10:50:56 +0200
+Subject: bus: ti-sysc: Flush posted write only after srst_udelay
+
+From: Tony Lindgren <tony@atomide.com>
+
+commit f71f6ff8c1f682a1cae4e8d7bdeed9d7f76b8f75 upstream.
+
+Commit 34539b442b3b ("bus: ti-sysc: Flush posted write on enable before
+reset") caused a regression reproducable on omap4 duovero where the ISS
+target module can produce interconnect errors on boot. Turns out the
+registers are not accessible until after a delay for devices needing
+a ti,sysc-delay-us value.
+
+Let's fix this by flushing the posted write only after the reset delay.
+We do flushing also for ti,sysc-delay-us using devices as that should
+trigger an interconnect error if the delay is not properly configured.
+
+Let's also add some comments while at it.
+
+Fixes: 34539b442b3b ("bus: ti-sysc: Flush posted write on enable before reset")
+Cc: stable@vger.kernel.org
+Signed-off-by: Tony Lindgren <tony@atomide.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/bus/ti-sysc.c | 18 ++++++++++++++----
+ 1 file changed, 14 insertions(+), 4 deletions(-)
+
+--- a/drivers/bus/ti-sysc.c
++++ b/drivers/bus/ti-sysc.c
+@@ -2104,13 +2104,23 @@ static int sysc_reset(struct sysc *ddata
+ sysc_val = sysc_read_sysconfig(ddata);
+ sysc_val |= sysc_mask;
+ sysc_write(ddata, sysc_offset, sysc_val);
+- /* Flush posted write */
++
++ /*
++ * Some devices need a delay before reading registers
++ * after reset. Presumably a srst_udelay is not needed
++ * for devices that use a rstctrl register reset.
++ */
++ if (ddata->cfg.srst_udelay)
++ fsleep(ddata->cfg.srst_udelay);
++
++ /*
++ * Flush posted write. For devices needing srst_udelay
++ * this should trigger an interconnect error if the
++ * srst_udelay value is needed but not configured.
++ */
+ sysc_val = sysc_read_sysconfig(ddata);
+ }
+
+- if (ddata->cfg.srst_udelay)
+- fsleep(ddata->cfg.srst_udelay);
+-
+ if (ddata->post_reset_quirk)
+ ddata->post_reset_quirk(ddata);
+
--- /dev/null
+From 1cc3542c76acb5f59001e3e562eba672f1983355 Mon Sep 17 00:00:00 2001
+From: xiongxin <xiongxin@kylinos.cn>
+Date: Wed, 20 Dec 2023 10:29:01 +0800
+Subject: gpio: dwapb: mask/unmask IRQ when disable/enale it
+
+From: xiongxin <xiongxin@kylinos.cn>
+
+commit 1cc3542c76acb5f59001e3e562eba672f1983355 upstream.
+
+In the hardware implementation of the I2C HID driver based on DesignWare
+GPIO IRQ chip, when the user continues to use the I2C HID device in the
+suspend process, the I2C HID interrupt will be masked after the resume
+process is finished.
+
+This is because the disable_irq()/enable_irq() of the DesignWare GPIO
+driver does not synchronize the IRQ mask register state. In normal use
+of the I2C HID procedure, the GPIO IRQ irq_mask()/irq_unmask() functions
+are called in pairs. In case of an exception, i2c_hid_core_suspend()
+calls disable_irq() to disable the GPIO IRQ. With low probability, this
+causes irq_unmask() to not be called, which causes the GPIO IRQ to be
+masked and not unmasked in enable_irq(), raising an exception.
+
+Add synchronization to the masked register state in the
+dwapb_irq_enable()/dwapb_irq_disable() function. mask the GPIO IRQ
+before disabling it. After enabling the GPIO IRQ, unmask the IRQ.
+
+Fixes: 7779b3455697 ("gpio: add a driver for the Synopsys DesignWare APB GPIO block")
+Cc: stable@kernel.org
+Co-developed-by: Riwen Lu <luriwen@kylinos.cn>
+Signed-off-by: Riwen Lu <luriwen@kylinos.cn>
+Signed-off-by: xiongxin <xiongxin@kylinos.cn>
+Acked-by: Serge Semin <fancer.lancer@gmail.com>
+Reviewed-by: Andy Shevchenko <andy@kernel.org>
+Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpio/gpio-dwapb.c | 12 ++++++++----
+ 1 file changed, 8 insertions(+), 4 deletions(-)
+
+--- a/drivers/gpio/gpio-dwapb.c
++++ b/drivers/gpio/gpio-dwapb.c
+@@ -277,13 +277,15 @@ static void dwapb_irq_enable(struct irq_
+ {
+ struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
+ struct dwapb_gpio *gpio = to_dwapb_gpio(gc);
++ irq_hw_number_t hwirq = irqd_to_hwirq(d);
+ unsigned long flags;
+ u32 val;
+
+ raw_spin_lock_irqsave(&gc->bgpio_lock, flags);
+- val = dwapb_read(gpio, GPIO_INTEN);
+- val |= BIT(irqd_to_hwirq(d));
++ val = dwapb_read(gpio, GPIO_INTEN) | BIT(hwirq);
+ dwapb_write(gpio, GPIO_INTEN, val);
++ val = dwapb_read(gpio, GPIO_INTMASK) & ~BIT(hwirq);
++ dwapb_write(gpio, GPIO_INTMASK, val);
+ raw_spin_unlock_irqrestore(&gc->bgpio_lock, flags);
+ }
+
+@@ -291,12 +293,14 @@ static void dwapb_irq_disable(struct irq
+ {
+ struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
+ struct dwapb_gpio *gpio = to_dwapb_gpio(gc);
++ irq_hw_number_t hwirq = irqd_to_hwirq(d);
+ unsigned long flags;
+ u32 val;
+
+ raw_spin_lock_irqsave(&gc->bgpio_lock, flags);
+- val = dwapb_read(gpio, GPIO_INTEN);
+- val &= ~BIT(irqd_to_hwirq(d));
++ val = dwapb_read(gpio, GPIO_INTMASK) | BIT(hwirq);
++ dwapb_write(gpio, GPIO_INTMASK, val);
++ val = dwapb_read(gpio, GPIO_INTEN) & ~BIT(hwirq);
+ dwapb_write(gpio, GPIO_INTEN, val);
+ raw_spin_unlock_irqrestore(&gc->bgpio_lock, flags);
+ }
--- /dev/null
+From 02e3858f08faabab9503ae2911cf7c7e27702257 Mon Sep 17 00:00:00 2001
+From: Marc Zyngier <maz@kernel.org>
+Date: Thu, 7 Dec 2023 15:11:59 +0000
+Subject: KVM: arm64: vgic: Force vcpu vgic teardown on vcpu destroy
+
+From: Marc Zyngier <maz@kernel.org>
+
+commit 02e3858f08faabab9503ae2911cf7c7e27702257 upstream.
+
+When failing to create a vcpu because (for example) it has a
+duplicate vcpu_id, we destroy the vcpu. Amusingly, this leaves
+the redistributor registered with the KVM_MMIO bus.
+
+This is no good, and we should properly clean the mess. Force
+a teardown of the vgic vcpu interface, including the RD device
+before returning to the caller.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Marc Zyngier <maz@kernel.org>
+Link: https://lore.kernel.org/r/20231207151201.3028710-4-maz@kernel.org
+Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/kvm/arm.c | 2 +-
+ arch/arm64/kvm/vgic/vgic-init.c | 5 ++++-
+ arch/arm64/kvm/vgic/vgic-mmio-v3.c | 2 +-
+ arch/arm64/kvm/vgic/vgic.h | 1 +
+ 4 files changed, 7 insertions(+), 3 deletions(-)
+
+--- a/arch/arm64/kvm/arm.c
++++ b/arch/arm64/kvm/arm.c
+@@ -356,7 +356,7 @@ void kvm_arch_vcpu_destroy(struct kvm_vc
+ kvm_mmu_free_memory_cache(&vcpu->arch.mmu_page_cache);
+ kvm_timer_vcpu_terminate(vcpu);
+ kvm_pmu_vcpu_destroy(vcpu);
+-
++ kvm_vgic_vcpu_destroy(vcpu);
+ kvm_arm_vcpu_destroy(vcpu);
+ }
+
+--- a/arch/arm64/kvm/vgic/vgic-init.c
++++ b/arch/arm64/kvm/vgic/vgic-init.c
+@@ -363,7 +363,10 @@ void kvm_vgic_vcpu_destroy(struct kvm_vc
+ vgic_flush_pending_lpis(vcpu);
+
+ INIT_LIST_HEAD(&vgic_cpu->ap_list_head);
+- vgic_cpu->rd_iodev.base_addr = VGIC_ADDR_UNDEF;
++ if (vcpu->kvm->arch.vgic.vgic_model == KVM_DEV_TYPE_ARM_VGIC_V3) {
++ vgic_unregister_redist_iodev(vcpu);
++ vgic_cpu->rd_iodev.base_addr = VGIC_ADDR_UNDEF;
++ }
+ }
+
+ /* To be called with kvm->lock held */
+--- a/arch/arm64/kvm/vgic/vgic-mmio-v3.c
++++ b/arch/arm64/kvm/vgic/vgic-mmio-v3.c
+@@ -744,7 +744,7 @@ int vgic_register_redist_iodev(struct kv
+ return 0;
+ }
+
+-static void vgic_unregister_redist_iodev(struct kvm_vcpu *vcpu)
++void vgic_unregister_redist_iodev(struct kvm_vcpu *vcpu)
+ {
+ struct vgic_io_device *rd_dev = &vcpu->arch.vgic_cpu.rd_iodev;
+
+--- a/arch/arm64/kvm/vgic/vgic.h
++++ b/arch/arm64/kvm/vgic/vgic.h
+@@ -223,6 +223,7 @@ int vgic_v3_lpi_sync_pending_status(stru
+ int vgic_v3_save_pending_tables(struct kvm *kvm);
+ int vgic_v3_set_redist_base(struct kvm *kvm, u32 index, u64 addr, u32 count);
+ int vgic_register_redist_iodev(struct kvm_vcpu *vcpu);
++void vgic_unregister_redist_iodev(struct kvm_vcpu *vcpu);
+ bool vgic_v3_check_base(struct kvm *kvm);
+
+ void vgic_v3_load(struct kvm_vcpu *vcpu);
--- /dev/null
+From 5c47251e8c4903111608ddcba2a77c0c425c247c Mon Sep 17 00:00:00 2001
+From: Herve Codina <herve.codina@bootlin.com>
+Date: Tue, 14 Nov 2023 16:26:55 +0100
+Subject: lib/vsprintf: Fix %pfwf when current node refcount == 0
+
+From: Herve Codina <herve.codina@bootlin.com>
+
+commit 5c47251e8c4903111608ddcba2a77c0c425c247c upstream.
+
+A refcount issue can appeared in __fwnode_link_del() due to the
+pr_debug() call:
+ WARNING: CPU: 0 PID: 901 at lib/refcount.c:25 refcount_warn_saturate+0xe5/0x110
+ Call Trace:
+ <TASK>
+ ...
+ of_node_get+0x1e/0x30
+ of_fwnode_get+0x28/0x40
+ fwnode_full_name_string+0x34/0x90
+ fwnode_string+0xdb/0x140
+ ...
+ vsnprintf+0x17b/0x630
+ ...
+ __fwnode_link_del+0x25/0xa0
+ fwnode_links_purge+0x39/0xb0
+ of_node_release+0xd9/0x180
+ ...
+
+Indeed, an fwnode (of_node) is being destroyed and so, of_node_release()
+is called because the of_node refcount reached 0.
+From of_node_release() several function calls are done and lead to
+a pr_debug() calls with %pfwf to print the fwnode full name.
+The issue is not present if we change %pfwf to %pfwP.
+
+To print the full name, %pfwf iterates over the current node and its
+parents and obtain/drop a reference to all nodes involved.
+
+In order to allow to print the full name (%pfwf) of a node while it is
+being destroyed, do not obtain/drop a reference to this current node.
+
+Fixes: a92eb7621b9f ("lib/vsprintf: Make use of fwnode API to obtain node names and separators")
+Cc: stable@vger.kernel.org
+Signed-off-by: Herve Codina <herve.codina@bootlin.com>
+Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
+Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Signed-off-by: Petr Mladek <pmladek@suse.com>
+Link: https://lore.kernel.org/r/20231114152655.409331-1-herve.codina@bootlin.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ lib/vsprintf.c | 11 ++++++++---
+ 1 file changed, 8 insertions(+), 3 deletions(-)
+
+--- a/lib/vsprintf.c
++++ b/lib/vsprintf.c
+@@ -2111,15 +2111,20 @@ char *fwnode_full_name_string(struct fwn
+
+ /* Loop starting from the root node to the current node. */
+ for (depth = fwnode_count_parents(fwnode); depth >= 0; depth--) {
+- struct fwnode_handle *__fwnode =
+- fwnode_get_nth_parent(fwnode, depth);
++ /*
++ * Only get a reference for other nodes (i.e. parent nodes).
++ * fwnode refcount may be 0 here.
++ */
++ struct fwnode_handle *__fwnode = depth ?
++ fwnode_get_nth_parent(fwnode, depth) : fwnode;
+
+ buf = string(buf, end, fwnode_get_name_prefix(__fwnode),
+ default_str_spec);
+ buf = string(buf, end, fwnode_get_name(__fwnode),
+ default_str_spec);
+
+- fwnode_handle_put(__fwnode);
++ if (depth)
++ fwnode_handle_put(__fwnode);
+ }
+
+ return buf;
--- /dev/null
+From 066c5b46b6eaf2f13f80c19500dbb3b84baabb33 Mon Sep 17 00:00:00 2001
+From: Alexander Atanasov <alexander.atanasov@virtuozzo.com>
+Date: Fri, 15 Dec 2023 14:10:08 +0200
+Subject: scsi: core: Always send batch on reset or error handling command
+
+From: Alexander Atanasov <alexander.atanasov@virtuozzo.com>
+
+commit 066c5b46b6eaf2f13f80c19500dbb3b84baabb33 upstream.
+
+In commit 8930a6c20791 ("scsi: core: add support for request batching") the
+block layer bd->last flag was mapped to SCMD_LAST and used as an indicator
+to send the batch for the drivers that implement this feature. However, the
+error handling code was not updated accordingly.
+
+scsi_send_eh_cmnd() is used to send error handling commands and request
+sense. The problem is that request sense comes as a single command that
+gets into the batch queue and times out. As a result the device goes
+offline after several failed resets. This was observed on virtio_scsi
+during a device resize operation.
+
+[ 496.316946] sd 0:0:4:0: [sdd] tag#117 scsi_eh_0: requesting sense
+[ 506.786356] sd 0:0:4:0: [sdd] tag#117 scsi_send_eh_cmnd timeleft: 0
+[ 506.787981] sd 0:0:4:0: [sdd] tag#117 abort
+
+To fix this always set SCMD_LAST flag in scsi_send_eh_cmnd() and
+scsi_reset_ioctl().
+
+Fixes: 8930a6c20791 ("scsi: core: add support for request batching")
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Alexander Atanasov <alexander.atanasov@virtuozzo.com>
+Link: https://lore.kernel.org/r/20231215121008.2881653-1-alexander.atanasov@virtuozzo.com
+Reviewed-by: Ming Lei <ming.lei@redhat.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/scsi/scsi_error.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/scsi/scsi_error.c
++++ b/drivers/scsi/scsi_error.c
+@@ -1104,6 +1104,7 @@ retry:
+
+ scsi_log_send(scmd);
+ scmd->submitter = SUBMITTED_BY_SCSI_ERROR_HANDLER;
++ scmd->flags |= SCMD_LAST;
+
+ /*
+ * Lock sdev->state_mutex to avoid that scsi_device_quiesce() can
+@@ -2397,6 +2398,7 @@ scsi_ioctl_reset(struct scsi_device *dev
+ scmd->cmnd = scsi_req(rq)->cmd;
+
+ scmd->submitter = SUBMITTED_BY_SCSI_RESET_IOCTL;
++ scmd->flags |= SCMD_LAST;
+ memset(&scmd->sdb, 0, sizeof(scmd->sdb));
+
+ scmd->cmd_len = 0;
net-rfkill-gpio-set-gpio-direction.patch
net-ks8851-fix-tx-stall-caused-by-tx-buffer-overrun.patch
dt-bindings-nvmem-mxs-ocotp-document-fsl-ocotp.patch
+spi-atmel-fix-clock-issue-when-using-devices-with-different-polarities.patch
+scsi-core-always-send-batch-on-reset-or-error-handling-command.patch
+tracing-synthetic-disable-events-after-testing-in-synth_event_gen_test_init.patch
+bus-ti-sysc-flush-posted-write-only-after-srst_udelay.patch
+gpio-dwapb-mask-unmask-irq-when-disable-enale-it.patch
+lib-vsprintf-fix-pfwf-when-current-node-refcount-0.patch
+kvm-arm64-vgic-force-vcpu-vgic-teardown-on-vcpu-destroy.patch
+x86-alternatives-sync-core-before-enabling-interrupts.patch
--- /dev/null
+From fc70d643a2f6678cbe0f5c86433c1aeb4d613fcc Mon Sep 17 00:00:00 2001
+From: Louis Chauvet <louis.chauvet@bootlin.com>
+Date: Mon, 4 Dec 2023 16:49:03 +0100
+Subject: spi: atmel: Fix clock issue when using devices with different polarities
+
+From: Louis Chauvet <louis.chauvet@bootlin.com>
+
+commit fc70d643a2f6678cbe0f5c86433c1aeb4d613fcc upstream.
+
+The current Atmel SPI controller driver (v2) behaves incorrectly when
+using two SPI devices with different clock polarities and GPIO CS.
+
+When switching from one device to another, the controller driver first
+enables the CS and then applies whatever configuration suits the targeted
+device (typically, the polarities). The side effect of such order is the
+apparition of a spurious clock edge after enabling the CS when the clock
+polarity needs to be inverted wrt. the previous configuration of the
+controller.
+
+This parasitic clock edge is problematic when the SPI device uses that edge
+for internal processing, which is perfectly legitimate given that its CS
+was asserted. Indeed, devices such as HVS8080 driven by driver gpio-sr in
+the kernel are shift registers and will process this first clock edge to
+perform a first register shift. In this case, the first bit gets lost and
+the whole data block that will later be read by the kernel is all shifted
+by one.
+
+ Current behavior:
+ The actual switching of the clock polarity only occurs after the CS
+ when the controller sends the first message:
+
+ CLK ------------\ /-\ /-\
+ | | | | | . . .
+ \---/ \-/ \
+ CS -----\
+ |
+ \------------------
+
+ ^ ^ ^
+ | | |
+ | | Actual clock of the message sent
+ | |
+ | Change of clock polarity, which occurs with the first
+ | write to the bus. This edge occurs when the CS is
+ | already asserted, and can be interpreted as
+ | the first clock edge by the receiver.
+ |
+ GPIO CS toggle
+
+This issue is specific to this controller because while the SPI core
+performs the operations in the right order, the controller however does
+not. In practice, the controller only applies the clock configuration right
+before the first transmission.
+
+So this is not a problem when using the controller's dedicated CS, as the
+controller does things correctly, but it becomes a problem when you need to
+change the clock polarity and use an external GPIO for the CS.
+
+One possible approach to solve this problem is to send a dummy message
+before actually activating the CS, so that the controller applies the clock
+polarity beforehand.
+
+New behavior:
+
+CLK ------\ /-\ /-\ /-\ /-\
+ | | | ... | | | | ... | |
+ \------/ \- -/ \------/ \- -/ \------
+
+CS -\/-----------------------\
+ || |
+ \/ \---------------------
+ ^ ^ ^ ^ ^
+ | | | | |
+ | | | | Expected clock cycles when
+ | | | | sending the message
+ | | | |
+ | | | Actual GPIO CS activation, occurs inside
+ | | | the driver
+ | | |
+ | | Dummy message, to trigger clock polarity
+ | | reconfiguration. This message is not received and
+ | | processed by the device because CS is low.
+ | |
+ | Change of clock polarity, forced by the dummy message. This
+ | time, the edge is not detected by the receiver.
+ |
+ This small spike in CS activation is due to the fact that the
+ spi-core activates the CS gpio before calling the driver's
+ set_cs callback, which deactivates this gpio again until the
+ clock polarity is correct.
+
+To avoid having to systematically send a dummy packet, the driver keeps
+track of the clock's current polarity. In this way, it only sends the dummy
+packet when necessary, ensuring that the clock will have the correct
+polarity when the CS is toggled.
+
+There could be two hardware problems with this patch:
+1- Maybe the small CS activation peak can confuse SPI devices
+2- If on a design, a single wire is used to select two devices depending
+on its state, the dummy message may disturb them.
+
+Fixes: 5ee36c989831 ("spi: atmel_spi update chipselect handling")
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com>
+Link: https://msgid.link/r/20231204154903.11607-1-louis.chauvet@bootlin.com
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/spi/spi-atmel.c | 82 +++++++++++++++++++++++++++++++++++++++++++++++-
+ 1 file changed, 81 insertions(+), 1 deletion(-)
+
+--- a/drivers/spi/spi-atmel.c
++++ b/drivers/spi/spi-atmel.c
+@@ -22,6 +22,7 @@
+ #include <linux/gpio/consumer.h>
+ #include <linux/pinctrl/consumer.h>
+ #include <linux/pm_runtime.h>
++#include <linux/iopoll.h>
+ #include <trace/events/spi.h>
+
+ /* SPI register offsets */
+@@ -278,6 +279,7 @@ struct atmel_spi {
+ bool keep_cs;
+
+ u32 fifo_size;
++ bool last_polarity;
+ u8 native_cs_free;
+ u8 native_cs_for_gpio;
+ };
+@@ -291,6 +293,22 @@ struct atmel_spi_device {
+ #define INVALID_DMA_ADDRESS 0xffffffff
+
+ /*
++ * This frequency can be anything supported by the controller, but to avoid
++ * unnecessary delay, the highest possible frequency is chosen.
++ *
++ * This frequency is the highest possible which is not interfering with other
++ * chip select registers (see Note for Serial Clock Bit Rate configuration in
++ * Atmel-11121F-ATARM-SAMA5D3-Series-Datasheet_02-Feb-16, page 1283)
++ */
++#define DUMMY_MSG_FREQUENCY 0x02
++/*
++ * 8 bits is the minimum data the controller is capable of sending.
++ *
++ * This message can be anything as it should not be treated by any SPI device.
++ */
++#define DUMMY_MSG 0xAA
++
++/*
+ * Version 2 of the SPI controller has
+ * - CR.LASTXFER
+ * - SPI_MR.DIV32 may become FDIV or must-be-zero (here: always zero)
+@@ -304,6 +322,43 @@ static bool atmel_spi_is_v2(struct atmel
+ }
+
+ /*
++ * Send a dummy message.
++ *
++ * This is sometimes needed when using a CS GPIO to force clock transition when
++ * switching between devices with different polarities.
++ */
++static void atmel_spi_send_dummy(struct atmel_spi *as, struct spi_device *spi, int chip_select)
++{
++ u32 status;
++ u32 csr;
++
++ /*
++ * Set a clock frequency to allow sending message on SPI bus.
++ * The frequency here can be anything, but is needed for
++ * the controller to send the data.
++ */
++ csr = spi_readl(as, CSR0 + 4 * chip_select);
++ csr = SPI_BFINS(SCBR, DUMMY_MSG_FREQUENCY, csr);
++ spi_writel(as, CSR0 + 4 * chip_select, csr);
++
++ /*
++ * Read all data coming from SPI bus, needed to be able to send
++ * the message.
++ */
++ spi_readl(as, RDR);
++ while (spi_readl(as, SR) & SPI_BIT(RDRF)) {
++ spi_readl(as, RDR);
++ cpu_relax();
++ }
++
++ spi_writel(as, TDR, DUMMY_MSG);
++
++ readl_poll_timeout_atomic(as->regs + SPI_SR, status,
++ (status & SPI_BIT(TXEMPTY)), 1, 1000);
++}
++
++
++/*
+ * Earlier SPI controllers (e.g. on at91rm9200) have a design bug whereby
+ * they assume that spi slave device state will not change on deselect, so
+ * that automagic deselection is OK. ("NPCSx rises if no data is to be
+@@ -319,11 +374,17 @@ static bool atmel_spi_is_v2(struct atmel
+ * Master on Chip Select 0.") No workaround exists for that ... so for
+ * nCS0 on that chip, we (a) don't use the GPIO, (b) can't support CS_HIGH,
+ * and (c) will trigger that first erratum in some cases.
++ *
++ * When changing the clock polarity, the SPI controller waits for the next
++ * transmission to enforce the default clock state. This may be an issue when
++ * using a GPIO as Chip Select: the clock level is applied only when the first
++ * packet is sent, once the CS has already been asserted. The workaround is to
++ * avoid this by sending a first (dummy) message before toggling the CS state.
+ */
+-
+ static void cs_activate(struct atmel_spi *as, struct spi_device *spi)
+ {
+ struct atmel_spi_device *asd = spi->controller_state;
++ bool new_polarity;
+ int chip_select;
+ u32 mr;
+
+@@ -352,6 +413,25 @@ static void cs_activate(struct atmel_spi
+ }
+
+ mr = spi_readl(as, MR);
++
++ /*
++ * Ensures the clock polarity is valid before we actually
++ * assert the CS to avoid spurious clock edges to be
++ * processed by the spi devices.
++ */
++ if (spi_get_csgpiod(spi, 0)) {
++ new_polarity = (asd->csr & SPI_BIT(CPOL)) != 0;
++ if (new_polarity != as->last_polarity) {
++ /*
++ * Need to disable the GPIO before sending the dummy
++ * message because it is already set by the spi core.
++ */
++ gpiod_set_value_cansleep(spi_get_csgpiod(spi, 0), 0);
++ atmel_spi_send_dummy(as, spi, chip_select);
++ as->last_polarity = new_polarity;
++ gpiod_set_value_cansleep(spi_get_csgpiod(spi, 0), 1);
++ }
++ }
+ } else {
+ u32 cpol = (spi->mode & SPI_CPOL) ? SPI_BIT(CPOL) : 0;
+ int i;
--- /dev/null
+From 88b30c7f5d27e1594d70dc2bd7199b18f2b57fa9 Mon Sep 17 00:00:00 2001
+From: "Steven Rostedt (Google)" <rostedt@goodmis.org>
+Date: Wed, 20 Dec 2023 11:15:25 -0500
+Subject: tracing / synthetic: Disable events after testing in synth_event_gen_test_init()
+
+From: Steven Rostedt (Google) <rostedt@goodmis.org>
+
+commit 88b30c7f5d27e1594d70dc2bd7199b18f2b57fa9 upstream.
+
+The synth_event_gen_test module can be built in, if someone wants to run
+the tests at boot up and not have to load them.
+
+The synth_event_gen_test_init() function creates and enables the synthetic
+events and runs its tests.
+
+The synth_event_gen_test_exit() disables the events it created and
+destroys the events.
+
+If the module is builtin, the events are never disabled. The issue is, the
+events should be disable after the tests are run. This could be an issue
+if the rest of the boot up tests are enabled, as they expect the events to
+be in a known state before testing. That known state happens to be
+disabled.
+
+When CONFIG_SYNTH_EVENT_GEN_TEST=y and CONFIG_EVENT_TRACE_STARTUP_TEST=y
+a warning will trigger:
+
+ Running tests on trace events:
+ Testing event create_synth_test:
+ Enabled event during self test!
+ ------------[ cut here ]------------
+ WARNING: CPU: 2 PID: 1 at kernel/trace/trace_events.c:4150 event_trace_self_tests+0x1c2/0x480
+ Modules linked in:
+ CPU: 2 PID: 1 Comm: swapper/0 Not tainted 6.7.0-rc2-test-00031-gb803d7c664d5-dirty #276
+ Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
+ RIP: 0010:event_trace_self_tests+0x1c2/0x480
+ Code: bb e8 a2 ab 5d fc 48 8d 7b 48 e8 f9 3d 99 fc 48 8b 73 48 40 f6 c6 01 0f 84 d6 fe ff ff 48 c7 c7 20 b6 ad bb e8 7f ab 5d fc 90 <0f> 0b 90 48 89 df e8 d3 3d 99 fc 48 8b 1b 4c 39 f3 0f 85 2c ff ff
+ RSP: 0000:ffffc9000001fdc0 EFLAGS: 00010246
+ RAX: 0000000000000029 RBX: ffff88810399ca80 RCX: 0000000000000000
+ RDX: 0000000000000000 RSI: ffffffffb9f19478 RDI: ffff88823c734e64
+ RBP: ffff88810399f300 R08: 0000000000000000 R09: fffffbfff79eb32a
+ R10: ffffffffbcf59957 R11: 0000000000000001 R12: ffff888104068090
+ R13: ffffffffbc89f0a0 R14: ffffffffbc8a0f08 R15: 0000000000000078
+ FS: 0000000000000000(0000) GS:ffff88823c700000(0000) knlGS:0000000000000000
+ CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+ CR2: 0000000000000000 CR3: 00000001f6282001 CR4: 0000000000170ef0
+ Call Trace:
+ <TASK>
+ ? __warn+0xa5/0x200
+ ? event_trace_self_tests+0x1c2/0x480
+ ? report_bug+0x1f6/0x220
+ ? handle_bug+0x6f/0x90
+ ? exc_invalid_op+0x17/0x50
+ ? asm_exc_invalid_op+0x1a/0x20
+ ? tracer_preempt_on+0x78/0x1c0
+ ? event_trace_self_tests+0x1c2/0x480
+ ? __pfx_event_trace_self_tests_init+0x10/0x10
+ event_trace_self_tests_init+0x27/0xe0
+ do_one_initcall+0xd6/0x3c0
+ ? __pfx_do_one_initcall+0x10/0x10
+ ? kasan_set_track+0x25/0x30
+ ? rcu_is_watching+0x38/0x60
+ kernel_init_freeable+0x324/0x450
+ ? __pfx_kernel_init+0x10/0x10
+ kernel_init+0x1f/0x1e0
+ ? _raw_spin_unlock_irq+0x33/0x50
+ ret_from_fork+0x34/0x60
+ ? __pfx_kernel_init+0x10/0x10
+ ret_from_fork_asm+0x1b/0x30
+ </TASK>
+
+This is because the synth_event_gen_test_init() left the synthetic events
+that it created enabled. By having it disable them after testing, the
+other selftests will run fine.
+
+Link: https://lore.kernel.org/linux-trace-kernel/20231220111525.2f0f49b0@gandalf.local.home
+
+Cc: stable@vger.kernel.org
+Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
+Cc: Tom Zanussi <zanussi@kernel.org>
+Fixes: 9fe41efaca084 ("tracing: Add synth event generation test module")
+Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
+Reported-by: Alexander Graf <graf@amazon.com>
+Tested-by: Alexander Graf <graf@amazon.com>
+Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/trace/synth_event_gen_test.c | 11 +++++++++++
+ 1 file changed, 11 insertions(+)
+
+--- a/kernel/trace/synth_event_gen_test.c
++++ b/kernel/trace/synth_event_gen_test.c
+@@ -477,6 +477,17 @@ static int __init synth_event_gen_test_i
+
+ ret = test_trace_synth_event();
+ WARN_ON(ret);
++
++ /* Disable when done */
++ trace_array_set_clr_event(gen_synth_test->tr,
++ "synthetic",
++ "gen_synth_test", false);
++ trace_array_set_clr_event(empty_synth_test->tr,
++ "synthetic",
++ "empty_synth_test", false);
++ trace_array_set_clr_event(create_synth_test->tr,
++ "synthetic",
++ "create_synth_test", false);
+ out:
+ return ret;
+ }
--- /dev/null
+From 3ea1704a92967834bf0e64ca1205db4680d04048 Mon Sep 17 00:00:00 2001
+From: Thomas Gleixner <tglx@linutronix.de>
+Date: Thu, 7 Dec 2023 20:49:24 +0100
+Subject: x86/alternatives: Sync core before enabling interrupts
+
+From: Thomas Gleixner <tglx@linutronix.de>
+
+commit 3ea1704a92967834bf0e64ca1205db4680d04048 upstream.
+
+text_poke_early() does:
+
+ local_irq_save(flags);
+ memcpy(addr, opcode, len);
+ local_irq_restore(flags);
+ sync_core();
+
+That's not really correct because the synchronization should happen before
+interrupts are re-enabled to ensure that a pending interrupt observes the
+complete update of the opcodes.
+
+It's not entirely clear whether the interrupt entry provides enough
+serialization already, but moving the sync_core() invocation into interrupt
+disabled region does no harm and is obviously correct.
+
+Fixes: 6fffacb30349 ("x86/alternatives, jumplabel: Use text_poke_early() before mm_init()")
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
+Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Cc: <stable@kernel.org>
+Link: https://lore.kernel.org/r/ZT6narvE%2BLxX%2B7Be@windriver.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kernel/alternative.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/x86/kernel/alternative.c
++++ b/arch/x86/kernel/alternative.c
+@@ -963,8 +963,8 @@ void __init_or_module text_poke_early(vo
+ } else {
+ local_irq_save(flags);
+ memcpy(addr, opcode, len);
+- local_irq_restore(flags);
+ sync_core();
++ local_irq_restore(flags);
+
+ /*
+ * Could also do a CLFLUSH here to speed up CPU recovery; but
projects / thirdparty / kernel / stable-queue.git / commitdiff
