From: Greg Kroah-Hartman Date: Sat, 30 Dec 2023 11:05:27 +0000 (+0000) Subject: 5.15-stable patches X-Git-Tag: v6.1.70~13 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=d4263b3bb6313a8414949c1c3244ea471a19e3a1;p=thirdparty%2Fkernel%2Fstable-queue.git 5.15-stable patches added patches: bus-ti-sysc-flush-posted-write-only-after-srst_udelay.patch gpio-dwapb-mask-unmask-irq-when-disable-enale-it.patch kvm-arm64-vgic-force-vcpu-vgic-teardown-on-vcpu-destroy.patch lib-vsprintf-fix-pfwf-when-current-node-refcount-0.patch scsi-core-always-send-batch-on-reset-or-error-handling-command.patch spi-atmel-fix-clock-issue-when-using-devices-with-different-polarities.patch tracing-synthetic-disable-events-after-testing-in-synth_event_gen_test_init.patch x86-alternatives-sync-core-before-enabling-interrupts.patch --- diff --git a/queue-5.15/bus-ti-sysc-flush-posted-write-only-after-srst_udelay.patch b/queue-5.15/bus-ti-sysc-flush-posted-write-only-after-srst_udelay.patch new file mode 100644 index 00000000000..a706fae6777 --- /dev/null +++ b/queue-5.15/bus-ti-sysc-flush-posted-write-only-after-srst_udelay.patch @@ -0,0 +1,59 @@ +From f71f6ff8c1f682a1cae4e8d7bdeed9d7f76b8f75 Mon Sep 17 00:00:00 2001 +From: Tony Lindgren +Date: Fri, 24 Nov 2023 10:50:56 +0200 +Subject: bus: ti-sysc: Flush posted write only after srst_udelay + +From: Tony Lindgren + +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 +Signed-off-by: Greg Kroah-Hartman +--- + 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); + diff --git a/queue-5.15/gpio-dwapb-mask-unmask-irq-when-disable-enale-it.patch b/queue-5.15/gpio-dwapb-mask-unmask-irq-when-disable-enale-it.patch new file mode 100644 index 00000000000..262437a8222 --- /dev/null +++ b/queue-5.15/gpio-dwapb-mask-unmask-irq-when-disable-enale-it.patch @@ -0,0 +1,76 @@ +From 1cc3542c76acb5f59001e3e562eba672f1983355 Mon Sep 17 00:00:00 2001 +From: xiongxin +Date: Wed, 20 Dec 2023 10:29:01 +0800 +Subject: gpio: dwapb: mask/unmask IRQ when disable/enale it + +From: xiongxin + +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 +Signed-off-by: Riwen Lu +Signed-off-by: xiongxin +Acked-by: Serge Semin +Reviewed-by: Andy Shevchenko +Signed-off-by: Bartosz Golaszewski +Signed-off-by: Greg Kroah-Hartman +--- + 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); + } diff --git a/queue-5.15/kvm-arm64-vgic-force-vcpu-vgic-teardown-on-vcpu-destroy.patch b/queue-5.15/kvm-arm64-vgic-force-vcpu-vgic-teardown-on-vcpu-destroy.patch new file mode 100644 index 00000000000..ea083d7683e --- /dev/null +++ b/queue-5.15/kvm-arm64-vgic-force-vcpu-vgic-teardown-on-vcpu-destroy.patch @@ -0,0 +1,75 @@ +From 02e3858f08faabab9503ae2911cf7c7e27702257 Mon Sep 17 00:00:00 2001 +From: Marc Zyngier +Date: Thu, 7 Dec 2023 15:11:59 +0000 +Subject: KVM: arm64: vgic: Force vcpu vgic teardown on vcpu destroy + +From: Marc Zyngier + +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 +Link: https://lore.kernel.org/r/20231207151201.3028710-4-maz@kernel.org +Signed-off-by: Oliver Upton +Signed-off-by: Greg Kroah-Hartman +--- + 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); diff --git a/queue-5.15/lib-vsprintf-fix-pfwf-when-current-node-refcount-0.patch b/queue-5.15/lib-vsprintf-fix-pfwf-when-current-node-refcount-0.patch new file mode 100644 index 00000000000..0364ac0f7d5 --- /dev/null +++ b/queue-5.15/lib-vsprintf-fix-pfwf-when-current-node-refcount-0.patch @@ -0,0 +1,77 @@ +From 5c47251e8c4903111608ddcba2a77c0c425c247c Mon Sep 17 00:00:00 2001 +From: Herve Codina +Date: Tue, 14 Nov 2023 16:26:55 +0100 +Subject: lib/vsprintf: Fix %pfwf when current node refcount == 0 + +From: Herve Codina + +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: + + ... + 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 +Reviewed-by: Sakari Ailus +Reviewed-by: Andy Shevchenko +Signed-off-by: Petr Mladek +Link: https://lore.kernel.org/r/20231114152655.409331-1-herve.codina@bootlin.com +Signed-off-by: Greg Kroah-Hartman +--- + 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; diff --git a/queue-5.15/scsi-core-always-send-batch-on-reset-or-error-handling-command.patch b/queue-5.15/scsi-core-always-send-batch-on-reset-or-error-handling-command.patch new file mode 100644 index 00000000000..de455441641 --- /dev/null +++ b/queue-5.15/scsi-core-always-send-batch-on-reset-or-error-handling-command.patch @@ -0,0 +1,56 @@ +From 066c5b46b6eaf2f13f80c19500dbb3b84baabb33 Mon Sep 17 00:00:00 2001 +From: Alexander Atanasov +Date: Fri, 15 Dec 2023 14:10:08 +0200 +Subject: scsi: core: Always send batch on reset or error handling command + +From: Alexander Atanasov + +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: +Signed-off-by: Alexander Atanasov +Link: https://lore.kernel.org/r/20231215121008.2881653-1-alexander.atanasov@virtuozzo.com +Reviewed-by: Ming Lei +Signed-off-by: Martin K. Petersen +Signed-off-by: Greg Kroah-Hartman +--- + 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; diff --git a/queue-5.15/series b/queue-5.15/series index f4f223eddaa..4b2e7c25deb 100644 --- a/queue-5.15/series +++ b/queue-5.15/series @@ -55,3 +55,11 @@ net-9p-avoid-freeing-uninit-memory-in-p9pdu_vreadf.patch 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 diff --git a/queue-5.15/spi-atmel-fix-clock-issue-when-using-devices-with-different-polarities.patch b/queue-5.15/spi-atmel-fix-clock-issue-when-using-devices-with-different-polarities.patch new file mode 100644 index 00000000000..2904f98def0 --- /dev/null +++ b/queue-5.15/spi-atmel-fix-clock-issue-when-using-devices-with-different-polarities.patch @@ -0,0 +1,241 @@ +From fc70d643a2f6678cbe0f5c86433c1aeb4d613fcc Mon Sep 17 00:00:00 2001 +From: Louis Chauvet +Date: Mon, 4 Dec 2023 16:49:03 +0100 +Subject: spi: atmel: Fix clock issue when using devices with different polarities + +From: Louis Chauvet + +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: +Signed-off-by: Louis Chauvet +Link: https://msgid.link/r/20231204154903.11607-1-louis.chauvet@bootlin.com +Signed-off-by: Mark Brown +Signed-off-by: Greg Kroah-Hartman +--- + 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 + #include + #include ++#include + #include + + /* 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; diff --git a/queue-5.15/tracing-synthetic-disable-events-after-testing-in-synth_event_gen_test_init.patch b/queue-5.15/tracing-synthetic-disable-events-after-testing-in-synth_event_gen_test_init.patch new file mode 100644 index 00000000000..45163124bc3 --- /dev/null +++ b/queue-5.15/tracing-synthetic-disable-events-after-testing-in-synth_event_gen_test_init.patch @@ -0,0 +1,110 @@ +From 88b30c7f5d27e1594d70dc2bd7199b18f2b57fa9 Mon Sep 17 00:00:00 2001 +From: "Steven Rostedt (Google)" +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) + +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: + + ? __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 + + +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 +Cc: Tom Zanussi +Fixes: 9fe41efaca084 ("tracing: Add synth event generation test module") +Acked-by: Masami Hiramatsu (Google) +Reported-by: Alexander Graf +Tested-by: Alexander Graf +Signed-off-by: Steven Rostedt (Google) +Signed-off-by: Greg Kroah-Hartman +--- + 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; + } diff --git a/queue-5.15/x86-alternatives-sync-core-before-enabling-interrupts.patch b/queue-5.15/x86-alternatives-sync-core-before-enabling-interrupts.patch new file mode 100644 index 00000000000..90ff9006b8a --- /dev/null +++ b/queue-5.15/x86-alternatives-sync-core-before-enabling-interrupts.patch @@ -0,0 +1,47 @@ +From 3ea1704a92967834bf0e64ca1205db4680d04048 Mon Sep 17 00:00:00 2001 +From: Thomas Gleixner +Date: Thu, 7 Dec 2023 20:49:24 +0100 +Subject: x86/alternatives: Sync core before enabling interrupts + +From: Thomas Gleixner + +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 +Signed-off-by: Borislav Petkov (AMD) +Acked-by: Peter Zijlstra (Intel) +Cc: +Link: https://lore.kernel.org/r/ZT6narvE%2BLxX%2B7Be@windriver.com +Signed-off-by: Greg Kroah-Hartman +--- + 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