linux-stable.git/drivers, branch v6.12.8

Bluetooth: btusb: mediatek: change the conditions for ISO interface

2025-01-02T09:34:25+00:00

commit defc33b5541e0a7e45cc2d99d72fbe80a597afc5 upstream.

Change conditions for Bluetooth driver claiming and releasing usb
ISO interface for MediaTek ISO data transmission.

Signed-off-by: Chris Lu 
Signed-off-by: Luiz Augusto von Dentz 
Cc: Fedor Pchelkin 
Signed-off-by: Greg Kroah-Hartman

Bluetooth: btusb: mediatek: add intf release flow when usb disconnect

2025-01-02T09:34:25+00:00

commit 489304e67087abddc2666c5af0159cb95afdcf59 upstream.

MediaTek claim an special usb intr interface for ISO data transmission.
The interface need to be released before unregistering hci device when
usb disconnect. Removing BT usb dongle without properly releasing the
interface may cause Kernel panic while unregister hci device.

Signed-off-by: Chris Lu 
Signed-off-by: Luiz Augusto von Dentz 
Cc: Fedor Pchelkin 
Signed-off-by: Greg Kroah-Hartman

Bluetooth: btusb: mediatek: add callback function in btusb_disconnect

2025-01-02T09:34:25+00:00

commit cea1805f165cdd783dd21f26df957118cb8641b4 upstream.

Add disconnect callback function in btusb_disconnect which is reserved
for vendor specific usage before deregister hci in btusb_disconnect.

Signed-off-by: Chris Lu 
Signed-off-by: Luiz Augusto von Dentz 
Cc: Fedor Pchelkin 
Signed-off-by: Greg Kroah-Hartman

Bluetooth: btusb: mediatek: move Bluetooth power off command position

2025-01-02T09:34:25+00:00

commit ad0c6f603bb0b07846fda484c59a176a8cd02838 upstream.

Move MediaTek Bluetooth power off command before releasing
usb ISO interface.

Signed-off-by: Chris Lu 
Signed-off-by: Luiz Augusto von Dentz 
Cc: Fedor Pchelkin 
Signed-off-by: Greg Kroah-Hartman

power: supply: gpio-charger: Fix set charge current limits

2025-01-02T09:34:24+00:00

commit afc6e39e824ad0e44b2af50a97885caec8d213d1 upstream.

Fix set charge current limits for devices which allow to set the lowest
charge current limit to be greater zero. If requested charge current limit
is below lowest limit, the index equals current_limit_map_size which leads
to accessing memory beyond allocated memory.

Fixes: be2919d8355e ("power: supply: gpio-charger: add charge-current-limit feature")
Cc: stable@vger.kernel.org
Signed-off-by: Dimitri Fedrau 
Link: https://lore.kernel.org/r/20241209-fix-charge-current-limit-v1-1-760d9b8f2af3@liebherr.com
Signed-off-by: Sebastian Reichel 
Signed-off-by: Greg Kroah-Hartman

power: supply: cros_charge-control: hide start threshold on v2 cmd

2025-01-02T09:34:23+00:00

commit c28dc9fc24f5fa802d44ef7620a511035bdd803e upstream.

ECs implementing the v2 command will not stop charging when the end
threshold is reached. Instead they will begin discharging until the
start threshold is reached, leading to permanent charge and discharge
cycles. This defeats the point of the charge control mechanism.

Avoid the issue by hiding the start threshold on v2 systems.
Instead on those systems program the EC with start == end which forces
the EC to reach and stay at that level.

v1 does not support thresholds and v3 works correctly,
at least judging from the code.

Reported-by: Thomas Koch 
Fixes: c6ed48ef5259 ("power: supply: add ChromeOS EC based charge control driver")
Cc: stable@vger.kernel.org
Signed-off-by: Thomas Weißschuh 
Link: https://lore.kernel.org/r/20241208-cros_charge-control-v2-v1-3-8d168d0f08a3@weissschuh.net
Signed-off-by: Sebastian Reichel 
Signed-off-by: Greg Kroah-Hartman

power: supply: cros_charge-control: allow start_threshold == end_threshold

2025-01-02T09:34:23+00:00

commit e65a1b7fad0e112573eea7d64d4ab4fc513b8695 upstream.

Allow setting the start and stop thresholds to the same value.
There is no reason to disallow it.

Suggested-by: Thomas Koch 
Fixes: c6ed48ef5259 ("power: supply: add ChromeOS EC based charge control driver")
Cc: stable@vger.kernel.org
Signed-off-by: Thomas Weißschuh 
Link: https://lore.kernel.org/r/20241208-cros_charge-control-v2-v1-2-8d168d0f08a3@weissschuh.net
Signed-off-by: Sebastian Reichel 
Signed-off-by: Greg Kroah-Hartman

power: supply: cros_charge-control: add mutex for driver data

2025-01-02T09:34:23+00:00

commit e5f84d1cf562f7b45e28d6e5f6490626f870f81c upstream.

Concurrent accesses through sysfs may lead to inconsistent state in the
priv data. Introduce a mutex to avoid this.

Fixes: c6ed48ef5259 ("power: supply: add ChromeOS EC based charge control driver")
Cc: stable@vger.kernel.org
Signed-off-by: Thomas Weißschuh 
Link: https://lore.kernel.org/r/20241208-cros_charge-control-v2-v1-1-8d168d0f08a3@weissschuh.net
Signed-off-by: Sebastian Reichel 
Signed-off-by: Greg Kroah-Hartman

i2c: microchip-core: fix "ghost" detections

2025-01-02T09:34:23+00:00

commit 49e1f0fd0d4cb03a16b8526c4e683e1958f71490 upstream.

Running i2c-detect currently produces an output akin to:
    0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         08 -- 0a -- 0c -- 0e --
10: 10 -- 12 -- 14 -- 16 -- UU 19 -- 1b -- 1d -- 1f
20: -- 21 -- 23 -- 25 -- 27 -- 29 -- 2b -- 2d -- 2f
30: -- -- -- -- -- -- -- -- 38 -- 3a -- 3c -- 3e --
40: 40 -- 42 -- 44 -- 46 -- 48 -- 4a -- 4c -- 4e --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: 60 -- 62 -- 64 -- 66 -- 68 -- 6a -- 6c -- 6e --
70: 70 -- 72 -- 74 -- 76 --

This happens because for an i2c_msg with a len of 0 the driver will
mark the transmission of the message as a success once the START has
been sent, without waiting for the devices on the bus to respond with an
ACK/NAK. Since i2cdetect seems to run in a tight loop over all addresses
the NAK is treated as part of the next test for the next address.

Delete the fast path that marks a message as complete when idev->msg_len
is zero after sending a START/RESTART since this isn't a valid scenario.

CC: stable@vger.kernel.org
Fixes: 64a6f1c4987e ("i2c: add support for microchip fpga i2c controllers")
Signed-off-by: Conor Dooley 
Reviewed-by: Andi Shyti 
Link: https://lore.kernel.org/r/20241218-outbid-encounter-b2e78b1cc707@spud
Signed-off-by: Andi Shyti 
Signed-off-by: Greg Kroah-Hartman

i2c: imx: add imx7d compatible string for applying erratum ERR007805

2025-01-02T09:34:23+00:00

commit e0cec363197e41af870613e8e17b30bf0e3d41b5 upstream.

Compatible string "fsl,imx7d-i2c" is not exited at i2c-imx driver
compatible string table, at the result, "fsl,imx21-i2c" will be
matched, but it will cause erratum ERR007805 not be applied in fact.

So Add "fsl,imx7d-i2c" compatible string in i2c-imx driver to apply
the erratum ERR007805(https://www.nxp.com/docs/en/errata/IMX7DS_3N09P.pdf).

"
ERR007805 I2C: When the I2C clock speed is configured for 400 kHz,
the SCL low period violates the I2C spec of 1.3 uS min

Description: When the I2C module is programmed to operate at the
maximum clock speed of 400 kHz (as defined by the I2C spec), the SCL
clock low period violates the I2C spec of 1.3 uS min. The user must
reduce the clock speed to obtain the SCL low time to meet the 1.3us
I2C minimum required. This behavior means the SoC is not compliant
to the I2C spec at 400kHz.

Workaround: To meet the clock low period requirement in fast speed
mode, SCL must be configured to 384KHz or less.
"

"fsl,imx7d-i2c" already is documented in binding doc. This erratum
fix has been included in imx6_i2c_hwdata and it is the same in all
I.MX6/7/8, so just reuse it.

Fixes: 39c025721d70 ("i2c: imx: Implement errata ERR007805 or e7805 bus frequency limit")
Cc: stable@vger.kernel.org # v5.18+
Signed-off-by: Carlos Song 
Signed-off-by: Haibo Chen 
Reviewed-by: Frank Li 
Fixes: 39c025721d70 ("i2c: imx: Implement errata ERR007805 or e7805 bus frequency limit")
Acked-by: Oleksij Rempel 
Link: https://lore.kernel.org/r/20241218044238.143414-1-carlos.song@nxp.com
Signed-off-by: Andi Shyti 
Signed-off-by: Greg Kroah-Hartman