user/sven/linux.git, branch v6.4.15

Linux 6.4.15

2023-09-06T20:25:33Z

Link: https://lore.kernel.org/r/20230904182947.899158313@linuxfoundation.org Tested-by: Joel Fernandes (Google) Tested-by: Bagas Sanjaya Tested-by: Linux Kernel Functional Testing Tested-by: Sudip Mukherjee Tested-by: Jon Hunter Tested-by: Justin M. Forbes Tested-by: Shuah Khan Tested-by: Florian Fainelli Tested-by: Ron Economos Tested-by: SeongJae Park Tested-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman

pinctrl: amd: Don't show `Invalid config param` errors

2023-09-06T20:25:33Z

commit 87b549efcb0f7934b0916d2a00607a878b6f1e0f upstream. On some systems amd_pinconf_set() is called with parameters 0x8 (PIN_CONFIG_DRIVE_PUSH_PULL) or 0x14 (PIN_CONFIG_PERSIST_STATE) which are not supported by pinctrl-amd. Don't show an err message when called with an invalid parameter, downgrade this to debug instead. Cc: stable@vger.kernel.org # 6.1 Fixes: 635a750d958e1 ("pinctrl: amd: Use amd_pinconf_set() for all config options") Signed-off-by: Mario Limonciello Link: https://lore.kernel.org/r/20230717201652.17168-1-mario.limonciello@amd.com Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman

usb: typec: tcpci: clear the fault status bit

2023-09-06T20:25:33Z

commit 23e60c8daf5ec2ab1b731310761b668745fcf6ed upstream. According the "USB Type-C Port Controller Interface Specification v2.0" the TCPC sets the fault status register bit-7 (AllRegistersResetToDefault) once the registers have been reset to their default values. This triggers an alert(-irq) on PTN5110 devices albeit we do mask the fault-irq, which may cause a kernel hang. Fix this generically by writing a one to the corresponding bit-7. Cc: stable@vger.kernel.org Fixes: 74e656d6b055 ("staging: typec: Type-C Port Controller Interface driver (tcpci)") Reported-by: "Angus Ainslie (Purism)" Closes: https://lore.kernel.org/all/20190508002749.14816-2-angus@akkea.ca/ Reported-by: Christian Bach Closes: https://lore.kernel.org/regressions/ZR0P278MB07737E5F1D48632897D51AC3EB329@ZR0P278MB0773.CHEP278.PROD.OUTLOOK.COM/t/ Signed-off-by: Marco Felsch Signed-off-by: Fabio Estevam Reviewed-by: Guenter Roeck Link: https://lore.kernel.org/r/20230816172502.1155079-1-festevam@gmail.com Signed-off-by: Greg Kroah-Hartman

nilfs2: fix WARNING in mark_buffer_dirty due to discarded buffer reuse

2023-09-06T20:25:32Z

commit cdaac8e7e5a059f9b5e816cda257f08d0abffacd upstream. A syzbot stress test using a corrupted disk image reported that mark_buffer_dirty() called from __nilfs_mark_inode_dirty() or nilfs_palloc_commit_alloc_entry() may output a kernel warning, and can panic if the kernel is booted with panic_on_warn. This is because nilfs2 keeps buffer pointers in local structures for some metadata and reuses them, but such buffers may be forcibly discarded by nilfs_clear_dirty_page() in some critical situations. This issue is reported to appear after commit 28a65b49eb53 ("nilfs2: do not write dirty data after degenerating to read-only"), but the issue has potentially existed before. Fix this issue by checking the uptodate flag when attempting to reuse an internally held buffer, and reloading the metadata instead of reusing the buffer if the flag was lost. Link: https://lkml.kernel.org/r/20230818131804.7758-1-konishi.ryusuke@gmail.com Signed-off-by: Ryusuke Konishi Reported-by: syzbot+cdfcae656bac88ba0e2d@syzkaller.appspotmail.com Closes: https://lkml.kernel.org/r/0000000000003da75f05fdeffd12@google.com Fixes: 8c26c4e2694a ("nilfs2: fix issue with flush kernel thread after remount in RO mode because of driver's internal error or metadata corruption") Tested-by: Ryusuke Konishi Cc: # 3.10+ Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman

dt-bindings: sc16is7xx: Add property to change GPIO function

2023-09-06T20:25:32Z

commit 4cf478dc5d707e56aefa258c049872eff054a353 upstream. Some variants in this series of UART controllers have GPIO pins that are shared between GPIO and modem control lines. The pin mux mode (GPIO or modem control lines) can be set for each ports (channels) supported by the variant. This adds a property to the device tree to set the GPIO pin mux to modem control lines on selected ports if needed. Cc: stable@vger.kernel.org # 6.1.x Signed-off-by: Hugo Villeneuve Acked-by: Conor Dooley Reviewed-by: Lech Perczak Acked-by: Rob Herring Link: https://lore.kernel.org/r/20230807214556.540627-4-hugo@hugovil.com Signed-off-by: Greg Kroah-Hartman

tcpm: Avoid soft reset when partner does not support get_status

2023-09-06T20:25:32Z

commit 78e0ea4277546debf7e96797ac3b768539cc44f6 upstream. When partner does not support get_status message, tcpm right now responds with soft reset message. This causes PD renegotiation to happen and resets PPS link. Avoid soft resetting the link when partner does not support get_status message to mitigate PPS resets. [ 208.926752] Setting voltage/current limit 9500 mV 2450 mA [ 208.930407] set_auto_vbus_discharge_threshold mode:3 pps_active:y vbus:9500 ret:0 [ 208.930418] state change SNK_TRANSITION_SINK -> SNK_READY [rev3 POWER_NEGOTIATION] [ 208.930455] AMS POWER_NEGOTIATION finished // ALERT message from the Source [ 213.948442] PD RX, header: 0x19a6 [1] [ 213.948451] state change SNK_READY -> GET_STATUS_SEND [rev3 GETTING_SOURCE_SINK_STATUS] [ 213.948457] PD TX, header: 0x492 [ 213.950402] PD TX complete, status: 0 [ 213.950427] pending state change GET_STATUS_SEND -> GET_STATUS_SEND_TIMEOUT @ 60 ms [rev3 GETTING_SOURCE_SINK_STATUS] // NOT_SUPPORTED from the Source [ 213.959954] PD RX, header: 0xbb0 [1] // sink sends SOFT_RESET [ 213.959958] state change GET_STATUS_SEND -> SNK_SOFT_RESET [rev3 GETTING_SOURCE_SINK_STATUS] [ 213.959962] AMS GETTING_SOURCE_SINK_STATUS finished [ 213.959964] AMS SOFT_RESET_AMS start [ 213.959966] state change SNK_SOFT_RESET -> AMS_START [rev3 SOFT_RESET_AMS] [ 213.959969] state change AMS_START -> SOFT_RESET_SEND [rev3 SOFT_RESET_AMS] Cc: stable@vger.kernel.org Fixes: 8dea75e11380 ("usb: typec: tcpm: Protocol Error handling") Signed-off-by: Badhri Jagan Sridharan Acked-by: Heikki Krogerus Link: https://lore.kernel.org/r/20230820044449.1005889-1-badhri@google.com Signed-off-by: Greg Kroah-Hartman

fsi: master-ast-cf: Add MODULE_FIRMWARE macro

2023-09-06T20:25:32Z

commit 3a1d7aff6e65ad6e285e28abe55abbfd484997ee upstream. The module loads firmware so add a MODULE_FIRMWARE macro to provide that information via modinfo. Fixes: 6a794a27daca ("fsi: master-ast-cf: Add new FSI master using Aspeed ColdFire") Cc: stable@vger.kernel.org # 4.19+ Signed-off-by: Juerg Haefliger Link: https://lore.kernel.org/r/20230628095039.26218-1-juerg.haefliger@canonical.com Signed-off-by: Joel Stanley Signed-off-by: Greg Kroah-Hartman

firmware: stratix10-svc: Fix an NULL vs IS_ERR() bug in probe

2023-09-06T20:25:32Z

commit dd218433f2b635d97e8fda3eed047151fd528ce4 upstream. The devm_memremap() function returns error pointers. It never returns NULL. Fix the check. Fixes: 7ca5ce896524 ("firmware: add Intel Stratix10 service layer driver") Cc: stable@vger.kernel.org Signed-off-by: Wang Ming Signed-off-by: Dinh Nguyen Link: https://lore.kernel.org/r/20230727193750.983795-1-dinguyen@kernel.org Signed-off-by: Greg Kroah-Hartman

serial: sc16is7xx: fix bug when first setting GPIO direction

2023-09-06T20:25:32Z

commit 9baeea723c0fb9c3ba9a336369f758ed9bc6831d upstream. When configuring a pin as an output pin with a value of logic 0, we end up as having a value of logic 1 on the output pin. Setting a logic 0 a second time (or more) after that will correctly output a logic 0 on the output pin. By default, all GPIO pins are configured as inputs. When we enter sc16is7xx_gpio_direction_output() for the first time, we first set the desired value in IOSTATE, and then we configure the pin as an output. The datasheet states that writing to IOSTATE register will trigger a transfer of the value to the I/O pin configured as output, so if the pin is configured as an input, nothing will be transferred. Therefore, set the direction first in IODIR, and then set the desired value in IOSTATE. This is what is done in NXP application note AN10587. Fixes: dfeae619d781 ("serial: sc16is7xx") Cc: stable@vger.kernel.org Signed-off-by: Hugo Villeneuve Reviewed-by: Lech Perczak Tested-by: Lech Perczak Link: https://lore.kernel.org/r/20230807214556.540627-6-hugo@hugovil.com Signed-off-by: Greg Kroah-Hartman

serial: sc16is7xx: fix broken port 0 uart init

2023-09-06T20:25:32Z

commit 2861ed4d6e6d1a2c9de9bf5b0abd996c2dc673d0 upstream. The sc16is7xx_config_rs485() function is called only for the second port (index 1, channel B), causing initialization problems for the first port. For the sc16is7xx driver, port->membase and port->mapbase are not set, and their default values are 0. And we set port->iobase to the device index. This means that when the first device is registered using the uart_add_one_port() function, the following values will be in the port structure: port->membase = 0 port->mapbase = 0 port->iobase = 0 Therefore, the function uart_configure_port() in serial_core.c will exit early because of the following check: /* * If there isn't a port here, don't do anything further. */ if (!port->iobase && !port->mapbase && !port->membase) return; Typically, I2C and SPI drivers do not set port->membase and port->mapbase. The max310x driver sets port->membase to ~0 (all ones). By implementing the same change in this driver, uart_configure_port() is now correctly executed for all ports. Fixes: dfeae619d781 ("serial: sc16is7xx") Cc: stable@vger.kernel.org Signed-off-by: Hugo Villeneuve Reviewed-by: Ilpo Järvinen Reviewed-by: Lech Perczak Tested-by: Lech Perczak Link: https://lore.kernel.org/r/20230807214556.540627-2-hugo@hugovil.com Signed-off-by: Greg Kroah-Hartman