Commit 84c9d2a968c82 ("HID: lenovo: Support for ThinkPad-X12-TAB-1/2 Kbd
Fn keys") added a dependency on ACPI's platform_profile. This should not
be done for generic USB devices as this prevents using the devices on
non ACPI devices like Apple silicon Macs and other non-ACPI arm64
systems. An attempt to allow using platform_profile on non-ACPI systems
was rejected in [1] and instead platform_profile was made to fail during
init in commit dd133162c9cf ("ACPI: platform_profile: Avoid initializing
on non-ACPI platforms").
So remove the broken dependency and instead let's user space handle this
keycode by sending the new KEY_PERFORMANCE. Stable backport depends on
commit 89c5214639294 ("Input: add keycode for performance mode key").
[1]: https://lore.kernel.org/linux-acpi/CAJZ5v0icRdTSToaKbdf=MdRin4NyB2MstUVaQo8…
Cc: regressions(a)lists.linux.dev
Cc: stable(a)vger.kernel.org
Fixes: 84c9d2a968c82 ("HID: lenovo: Support for ThinkPad-X12-TAB-1/2 Kbd Fn keys")
Signed-off-by: Janne Grunau <j(a)jannau.net>
---
#regzbot introduced: 84c9d2a968c82
---
drivers/hid/Kconfig | 2 --
drivers/hid/hid-lenovo.c | 4 +---
2 files changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index a57901203aeb284acd23be727d2fad0c137c101c..8ae63f8257cd582448e9683ca7fc654c8e465c0f 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -597,8 +597,6 @@ config HID_LED
config HID_LENOVO
tristate "Lenovo / Thinkpad devices"
- depends on ACPI
- select ACPI_PLATFORM_PROFILE
select NEW_LEDS
select LEDS_CLASS
help
diff --git a/drivers/hid/hid-lenovo.c b/drivers/hid/hid-lenovo.c
index b3121fa7a72d73f2b9ac12f36bc3d87c2649c69b..654879814f97aaf876ac16c00bf9efca22d116f3 100644
--- a/drivers/hid/hid-lenovo.c
+++ b/drivers/hid/hid-lenovo.c
@@ -32,8 +32,6 @@
#include <linux/leds.h>
#include <linux/workqueue.h>
-#include <linux/platform_profile.h>
-
#include "hid-ids.h"
/* Userspace expects F20 for mic-mute KEY_MICMUTE does not work */
@@ -734,7 +732,7 @@ static int lenovo_raw_event_TP_X12_tab(struct hid_device *hdev, u32 raw_data)
report_key_event(input, KEY_RFKILL);
return 1;
}
- platform_profile_cycle();
+ report_key_event(input, KEY_PERFORMANCE);
return 1;
case TP_X12_RAW_HOTKEY_FN_F10:
/* TAB1 has PICKUP Phone and TAB2 use Snipping tool*/
---
base-commit: 8f5ae30d69d7543eee0d70083daf4de8fe15d585
change-id: 20250901-hid-lenovo-drop-platform_profile-d59013f79a59
Best regards,
--
Janne Grunau <j(a)jannau.net>
> On Wed, Sep 10, 2025 at 05:31:38PM +0000, Eliav Farber wrote:
>> Fix a compilation failure when warnings are treated as errors:
>>
>> drivers/net/ethernet/intel/e1000e/ethtool.c: In function ‘e1000_set_eeprom’:
>> ./include/linux/overflow.h:71:15: error: comparison of distinct pointer types lacks a cast [-Werror]
>> 71 | (void) (&__a == __d); \
>> | ^~
>> drivers/net/ethernet/intel/e1000e/ethtool.c:582:6: note: in expansion of macro ‘check_add_overflow’
>> 582 | if (check_add_overflow(eeprom->offset, eeprom->len, &total_len) ||
>> | ^~~~~~~~~~~~~~~~~~
>>
>> To fix this, change total_len and max_len from size_t to u32 in
>> e1000_set_eeprom().
>> The check_add_overflow() helper requires that the first two operands
>> and the pointer to the result (third operand) all have the same type.
>> On 64-bit builds, using size_t caused a mismatch with the u32 fields
>> eeprom->offset and eeprom->len, leading to type check failures.
>>
>> Fixes: ce8829d3d44b ("e1000e: fix heap overflow in e1000_set_eeprom")
>> Signed-off-by: Eliav Farber <farbere(a)amazon.com>
>> ---
>> drivers/net/ethernet/intel/e1000e/ethtool.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/ethernet/intel/e1000e/ethtool.c
>> b/drivers/net/ethernet/intel/e1000e/ethtool.c
>> index 4aca854783e2..584378291f3f 100644
>> --- a/drivers/net/ethernet/intel/e1000e/ethtool.c
>> +++ b/drivers/net/ethernet/intel/e1000e/ethtool.c
>> @@ -559,7 +559,7 @@ static int e1000_set_eeprom(struct net_device
>> *netdev, {
>> struct e1000_adapter *adapter = netdev_priv(netdev);
>> struct e1000_hw *hw = &adapter->hw;
>> - size_t total_len, max_len;
>> + u32 total_len, max_len;
>> u16 *eeprom_buff;
>> int ret_val = 0;
>> int first_word;
>> --
>> 2.47.3
>>
>
> Why is this not needed in Linus's tree?
Kernel 5.10.243 enforces the same type, but this enforcement is
absent from 5.15.192 and later:
/*
* For simplicity and code hygiene, the fallback code below insists on
* a, b and *d having the same type (similar to the min() and max()
* macros), whereas gcc's type-generic overflow checkers accept
* different types. Hence we don't just make check_add_overflow an
* alias for __builtin_add_overflow, but add type checks similar to
* below.
*/
#define check_add_overflow(a, b, d) __must_check_overflow(({ \
> Also, why is it not cc: stable(a)vger.kernel.org?
Added to cc.
---
Regards, Eliav
--
Hello,
We are interested in purchasing your products and would like to confirm
if you are currently accepting new orders.
Please let us know at your earliest convenience so we can proceed
accordingly.
Best Regards,
Stefanie U Weisz
PCB TRADING COMPANY Ltd
Address: Eschenweg 124, Greiz, Freistaat Thüringen,
Vilnius, Netherlands.
Commit "arm64: dts: marvell: only enable complete sata nodes" changed
armada-cp11x.dtsi disabling all sata ports status by default.
The author missed some dts which relied on the dtsi enabling all ports,
and just disabled unused ones instead.
Update dts for SolidRun cn913x based boards to enable the available
ports, rather than disabling the unvavailable one.
Further according to dt bindings the serdes phys are to be specified in
the port node, not the controller node.
Move those phys properties accordingly in clearfog base/pro/solidwan.
Fixes: 30023876aef4 ("arm64: dts: marvell: only enable complete sata nodes")
Cc: stable(a)vger.kernel.org
Signed-off-by: Josua Mayer <josua(a)solid-run.com>
---
arch/arm64/boot/dts/marvell/cn9130-cf.dtsi | 7 ++++---
arch/arm64/boot/dts/marvell/cn9131-cf-solidwan.dts | 6 ++++--
arch/arm64/boot/dts/marvell/cn9132-clearfog.dts | 6 ++----
3 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/arch/arm64/boot/dts/marvell/cn9130-cf.dtsi b/arch/arm64/boot/dts/marvell/cn9130-cf.dtsi
index ad0ab34b66028c53b8a18b3e8ee0c0aec869759f..bd42bfbe408bbe2a4d58dbd40204bcfb3c126312 100644
--- a/arch/arm64/boot/dts/marvell/cn9130-cf.dtsi
+++ b/arch/arm64/boot/dts/marvell/cn9130-cf.dtsi
@@ -152,11 +152,12 @@ expander0_pins: cp0-expander0-pins {
/* SRDS #0 - SATA on M.2 connector */
&cp0_sata0 {
- phys = <&cp0_comphy0 1>;
status = "okay";
- /* only port 1 is available */
- /delete-node/ sata-port@0;
+ sata-port@1 {
+ phys = <&cp0_comphy0 1>;
+ status = "okay";
+ };
};
/* microSD */
diff --git a/arch/arm64/boot/dts/marvell/cn9131-cf-solidwan.dts b/arch/arm64/boot/dts/marvell/cn9131-cf-solidwan.dts
index 47234d0858dd2195bb1485f25768ad3c757b7ac2..338853d3b179bb5cb742e975bb830fdb9d62d4cc 100644
--- a/arch/arm64/boot/dts/marvell/cn9131-cf-solidwan.dts
+++ b/arch/arm64/boot/dts/marvell/cn9131-cf-solidwan.dts
@@ -563,11 +563,13 @@ &cp1_rtc {
/* SRDS #1 - SATA on M.2 (J44) */
&cp1_sata0 {
- phys = <&cp1_comphy1 0>;
status = "okay";
/* only port 0 is available */
- /delete-node/ sata-port@1;
+ sata-port@0 {
+ phys = <&cp1_comphy1 0>;
+ status = "okay";
+ };
};
&cp1_syscon0 {
diff --git a/arch/arm64/boot/dts/marvell/cn9132-clearfog.dts b/arch/arm64/boot/dts/marvell/cn9132-clearfog.dts
index 0f53745a6fa0d8cbd3ab9cdc28a972ed748c275f..115c55d73786e2b9265e1caa4c62ee26f498fb41 100644
--- a/arch/arm64/boot/dts/marvell/cn9132-clearfog.dts
+++ b/arch/arm64/boot/dts/marvell/cn9132-clearfog.dts
@@ -512,10 +512,9 @@ &cp1_sata0 {
status = "okay";
/* only port 1 is available */
- /delete-node/ sata-port@0;
-
sata-port@1 {
phys = <&cp1_comphy3 1>;
+ status = "okay";
};
};
@@ -631,9 +630,8 @@ &cp2_sata0 {
status = "okay";
/* only port 1 is available */
- /delete-node/ sata-port@0;
-
sata-port@1 {
+ status = "okay";
phys = <&cp2_comphy3 1>;
};
};
---
base-commit: 8f5ae30d69d7543eee0d70083daf4de8fe15d585
change-id: 20250911-cn913x-sr-fix-sata-5c737ebdb97f
Best regards,
--
Josua Mayer <josua(a)solid-run.com>
The mhi_ep_read_channel function incorrectly assumes the End of Transfer
(EOT) bit is received with the doorbell in chained transactions, causing
it to advance mhi_chan->rd_offset beyond wr_offset during host-to-device
transfers when EOT has not yet arrived, leading to access of unmapped host
memory that causes IOMMU faults and processing of stale TREs.
Modify the loop condition to ensure mhi_queue is not empty, allowing the
function to process only valid TREs up to the current write pointer to
prevent premature reads and ensure safe traversal of chained TREs.
Remove buf_left from the while loop condition to avoid exiting prematurely
before reading the ring completely, and remove write_offset since it will
always be zero because the new cache buffer is allocated every time.
Fixes: 5301258899773 ("bus: mhi: ep: Add support for reading from the host")
Cc: stable(a)vger.kernel.org
Co-developed-by: Akhil Vinod <akhil.vinod(a)oss.qualcomm.com>
Signed-off-by: Akhil Vinod <akhil.vinod(a)oss.qualcomm.com>
Signed-off-by: Sumit Kumar <sumit.kumar(a)oss.qualcomm.com>
---
Changes in v3:
- Update commit message
- Migrated to new mail
- Link to v2: https://lore.kernel.org/r/20250822-chained_transfer-v2-1-7aeb5ac215b6@quici…
Changes in v2:
- Use mhi_ep_queue_is_empty in while loop (Mani).
- Remove do while loop in mhi_ep_process_ch_ring (Mani).
- Remove buf_left, wr_offset, tr_done.
- Haven't added Reviewed-by as there is change in logic.
- Link to v1: https://lore.kernel.org/r/20250709-chained_transfer-v1-1-2326a4605c9c@quici…
---
drivers/bus/mhi/ep/main.c | 37 ++++++++++++-------------------------
1 file changed, 12 insertions(+), 25 deletions(-)
diff --git a/drivers/bus/mhi/ep/main.c b/drivers/bus/mhi/ep/main.c
index b3eafcf2a2c50d95e3efd3afb27038ecf55552a5..cdea24e9291959ae0a92487c1b9698dc8164d2f1 100644
--- a/drivers/bus/mhi/ep/main.c
+++ b/drivers/bus/mhi/ep/main.c
@@ -403,17 +403,13 @@ static int mhi_ep_read_channel(struct mhi_ep_cntrl *mhi_cntrl,
{
struct mhi_ep_chan *mhi_chan = &mhi_cntrl->mhi_chan[ring->ch_id];
struct device *dev = &mhi_cntrl->mhi_dev->dev;
- size_t tr_len, read_offset, write_offset;
+ size_t tr_len, read_offset;
struct mhi_ep_buf_info buf_info = {};
u32 len = MHI_EP_DEFAULT_MTU;
struct mhi_ring_element *el;
- bool tr_done = false;
void *buf_addr;
- u32 buf_left;
int ret;
- buf_left = len;
-
do {
/* Don't process the transfer ring if the channel is not in RUNNING state */
if (mhi_chan->state != MHI_CH_STATE_RUNNING) {
@@ -426,24 +422,23 @@ static int mhi_ep_read_channel(struct mhi_ep_cntrl *mhi_cntrl,
/* Check if there is data pending to be read from previous read operation */
if (mhi_chan->tre_bytes_left) {
dev_dbg(dev, "TRE bytes remaining: %u\n", mhi_chan->tre_bytes_left);
- tr_len = min(buf_left, mhi_chan->tre_bytes_left);
+ tr_len = min(len, mhi_chan->tre_bytes_left);
} else {
mhi_chan->tre_loc = MHI_TRE_DATA_GET_PTR(el);
mhi_chan->tre_size = MHI_TRE_DATA_GET_LEN(el);
mhi_chan->tre_bytes_left = mhi_chan->tre_size;
- tr_len = min(buf_left, mhi_chan->tre_size);
+ tr_len = min(len, mhi_chan->tre_size);
}
read_offset = mhi_chan->tre_size - mhi_chan->tre_bytes_left;
- write_offset = len - buf_left;
buf_addr = kmem_cache_zalloc(mhi_cntrl->tre_buf_cache, GFP_KERNEL);
if (!buf_addr)
return -ENOMEM;
buf_info.host_addr = mhi_chan->tre_loc + read_offset;
- buf_info.dev_addr = buf_addr + write_offset;
+ buf_info.dev_addr = buf_addr;
buf_info.size = tr_len;
buf_info.cb = mhi_ep_read_completion;
buf_info.cb_buf = buf_addr;
@@ -459,16 +454,12 @@ static int mhi_ep_read_channel(struct mhi_ep_cntrl *mhi_cntrl,
goto err_free_buf_addr;
}
- buf_left -= tr_len;
mhi_chan->tre_bytes_left -= tr_len;
- if (!mhi_chan->tre_bytes_left) {
- if (MHI_TRE_DATA_GET_IEOT(el))
- tr_done = true;
-
+ if (!mhi_chan->tre_bytes_left)
mhi_chan->rd_offset = (mhi_chan->rd_offset + 1) % ring->ring_size;
- }
- } while (buf_left && !tr_done);
+ /* Read until the some buffer is left or the ring becomes not empty */
+ } while (!mhi_ep_queue_is_empty(mhi_chan->mhi_dev, DMA_TO_DEVICE));
return 0;
@@ -502,15 +493,11 @@ static int mhi_ep_process_ch_ring(struct mhi_ep_ring *ring)
mhi_chan->xfer_cb(mhi_chan->mhi_dev, &result);
} else {
/* UL channel */
- do {
- ret = mhi_ep_read_channel(mhi_cntrl, ring);
- if (ret < 0) {
- dev_err(&mhi_chan->mhi_dev->dev, "Failed to read channel\n");
- return ret;
- }
-
- /* Read until the ring becomes empty */
- } while (!mhi_ep_queue_is_empty(mhi_chan->mhi_dev, DMA_TO_DEVICE));
+ ret = mhi_ep_read_channel(mhi_cntrl, ring);
+ if (ret < 0) {
+ dev_err(&mhi_chan->mhi_dev->dev, "Failed to read channel\n");
+ return ret;
+ }
}
return 0;
---
base-commit: 4c06e63b92038fadb566b652ec3ec04e228931e8
change-id: 20250910-final_chained-750c213725f1
Best regards,
--
Sumit Kumar <sumit.kumar(a)oss.qualcomm.com>
If copy_from_user() fails, write() currently returns -EFAULT, but any
partially written data leaves the TX FIFO in an inconsistent state.
Subsequent write() calls then fail with "transmit length mismatch"
errors.
Once partial data is written to the hardware FIFO, it cannot be removed
without a TX reset. Commit c6e8d85fafa7 ("staging: axis-fifo: Remove
hardware resets for user errors") removed a full FIFO reset for this case,
which fixed a potential RX data loss, but introduced this TX issue.
Fix this by introducing a bounce buffer: copy the full packet from
userspace first, and write to the hardware FIFO only if the copy
was successful.
Fixes: c6e8d85fafa7 ("staging: axis-fifo: Remove hardware resets for user errors")
Cc: stable(a)vger.kernel.org
Signed-off-by: Ovidiu Panait <ovidiu.panait.oss(a)gmail.com>
---
drivers/staging/axis-fifo/axis-fifo.c | 36 ++++++++-------------------
1 file changed, 10 insertions(+), 26 deletions(-)
diff --git a/drivers/staging/axis-fifo/axis-fifo.c b/drivers/staging/axis-fifo/axis-fifo.c
index f54614ba1aa8..c47c6a022402 100644
--- a/drivers/staging/axis-fifo/axis-fifo.c
+++ b/drivers/staging/axis-fifo/axis-fifo.c
@@ -43,7 +43,6 @@
#define DRIVER_NAME "axis_fifo"
#define READ_BUF_SIZE 128U /* read buffer length in words */
-#define WRITE_BUF_SIZE 128U /* write buffer length in words */
#define AXIS_FIFO_DEBUG_REG_NAME_MAX_LEN 4
@@ -305,11 +304,8 @@ static ssize_t axis_fifo_write(struct file *f, const char __user *buf,
{
struct axis_fifo *fifo = (struct axis_fifo *)f->private_data;
unsigned int words_to_write;
- unsigned int copied;
- unsigned int copy;
- unsigned int i;
+ u32 *txbuf;
int ret;
- u32 tmp_buf[WRITE_BUF_SIZE];
if (len % sizeof(u32)) {
dev_err(fifo->dt_device,
@@ -374,32 +370,20 @@ static ssize_t axis_fifo_write(struct file *f, const char __user *buf,
}
}
- /* write data from an intermediate buffer into the fifo IP, refilling
- * the buffer with userspace data as needed
- */
- copied = 0;
- while (words_to_write > 0) {
- copy = min(words_to_write, WRITE_BUF_SIZE);
-
- if (copy_from_user(tmp_buf, buf + copied * sizeof(u32),
- copy * sizeof(u32))) {
- ret = -EFAULT;
- goto end_unlock;
- }
-
- for (i = 0; i < copy; i++)
- iowrite32(tmp_buf[i], fifo->base_addr +
- XLLF_TDFD_OFFSET);
-
- copied += copy;
- words_to_write -= copy;
+ txbuf = vmemdup_user(buf, len);
+ if (IS_ERR(txbuf)) {
+ ret = PTR_ERR(txbuf);
+ goto end_unlock;
}
- ret = copied * sizeof(u32);
+ for (int i = 0; i < words_to_write; ++i)
+ iowrite32(txbuf[i], fifo->base_addr + XLLF_TDFD_OFFSET);
/* write packet size to fifo */
- iowrite32(ret, fifo->base_addr + XLLF_TLR_OFFSET);
+ iowrite32(len, fifo->base_addr + XLLF_TLR_OFFSET);
+ ret = len;
+ kvfree(txbuf);
end_unlock:
mutex_unlock(&fifo->write_lock);
--
2.50.0
Hello,
This series is based on commit
320475fbd590 Merge tag 'mtd/fixes-for-6.17-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux
of Mainline Linux.
The first patch in the series has been posted as a Fix in contrast to
its predecessor at:
https://lore.kernel.org/r/20250903124505.365913-10-s-vadapalli@ti.com/
based on the feedback provided by Jiri Slaby <jirislaby(a)kernel.org> at:
https://lore.kernel.org/r/3d3a4b52-e343-42f3-9d69-94c259812143@kernel.org/
Since the Fix is independent of enabling loadable module support for the
pci-keystone.c driver, it is being posted as a new patch.
Checking out at the commit of Mainline Linux which this series is based
on, I noticed an exception triggered by the pci-keystone.c driver during
its probe. Although this is not a fatal exception and Linux continues to
boot, the driver is non-functional. I root-caused the exception to
free_initmem() freeing the memory associated with the ks_pcie_host_init()
function in the driver before the driver's probe was invoked. This
appears to be a race condition but it is easily reproducible with the
Linux .config that I have used. The fix therefore is to remove the
__init macro which is implemented by the second patch in the series.
For reference, the logs for the case where Linux is built by checking
out at the base commit of Mainline Linux are:
https://gist.github.com/Siddharth-Vadapalli-at-TI/f4891b707921c53dfb464ad2f…
and the logs clearly prove that the print associated with free_initmem()
which is:
[ 2.446834] Freeing unused kernel memory: 4864K
is displayed prior to the prints associated with the pci-keystone.c
driver being probed which is:
[ 7.707103] keystone-pcie 5500000.pcie: host bridge /bus@100000/pcie@5500000 ranges:
Building Linux by applying both patches in the series on the base commit of
Mainline Linux, the driver probes successfully without any exceptions or
errors. This was tested on AM654-EVM with an NVMe SSD connected to the
PCIe Connector on the board. The NVMe SSD enumerates successfully.
Additionally, the 'hdparm' utility was used to read from the SSD
confirming that the SSD is functional. The logs corresponding to this are:
https://gist.github.com/Siddharth-Vadapalli-at-TI/1b09a12a53db4233e82c5bcfc…
Regards,
Siddharth.
Siddharth Vadapalli (2):
PCI: keystone: Use devm_request_irq() to free "ks-pcie-error-irq" on
exit
PCI: keystone: Remove the __init macro for the ks_pcie_host_init()
callback
drivers/pci/controller/dwc/pci-keystone.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--
2.43.0