summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2023-04-20tty: vt: simplify some cases in tioclinux()Jiri Slaby (SUSE)
There is no need to set "ret" variable and break. We can simply return from the cases. This makes the code much easier to follow, as many else branches are redundant. Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org> Link: https://lore.kernel.org/r/20230420093559.13200-2-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20tty: vt: reformat tioclinux()Jiri Slaby (SUSE)
Reformat tioclinux() to what we are used to. That is: * format switch-case (one less indent level), * format comments (the same indent level), and * add a newline before return. Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org> Link: https://lore.kernel.org/r/20230420093559.13200-1-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20tty: serial: sh-sci: Fix end of transmission on SCIBiju Das
We need to set TE to "0" (i.e., disable serial transmission) to get the expected behavior of the end of serial transmission. Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://lore.kernel.org/r/20230412145053.114847-6-biju.das.jz@bp.renesas.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20tty: serial: sh-sci: Add support for tx end interrupt handlingBiju Das
As per the RZ/G2L users hardware manual (Rev.1.20 Sep, 2022), section 23.3.7 Serial Data Transmission (Asynchronous Mode), it is mentioned that, set the SCR.TIE bit to 0 and SCR.TEIE bit to 1, after the last data to be transmitted are written to the TDR. This will generate tx end interrupt and in the handler set SCR.TE and SCR.TEIE to 0. Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://lore.kernel.org/r/20230412145053.114847-5-biju.das.jz@bp.renesas.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20tty: serial: sh-sci: Fix TE setting on SCI IPBiju Das
As per the RZ/G2L users hardware manual (Rev.1.20 Sep, 2022), section 23.3.7 Serial Data Transmission (Asynchronous Mode) it is mentioned that the TE (transmit enable) must be set after setting TIE (transmit interrupt enable) or these 2 bits are set to 1 simultaneously by a single instruction. So set these 2 bits in single instruction. Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://lore.kernel.org/r/20230412145053.114847-4-biju.das.jz@bp.renesas.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20tty: serial: sh-sci: Add RZ/G2L SCIFA DMA rx supportBiju Das
SCIFA IP on RZ/G2L SoC has the same signal for both interrupt and DMA transfer request. Setting DMARS register for DMA transfer makes the signal to work as a DMA transfer request signal and subsequent interrupt requests to the interrupt controller are masked. Similarly clearing DMARS register makes signal to work as interrupt signal and subsequent interrupt requests to the interrupt controller are unmasked. Add SCIFA DMA rx support for RZ/G2L alike SoCs by disabling RXI line interrupt and setting DMARS registers by DMA api for DMA transfer request. Apart from this, we must set FIFO trigger to 1 for the expected behavior of the receive transmission. While at it replace the parameter irq to s->irqs[SCIx_RXI_IRQ] in disable_irq_nosync() to match enable_irq() in sci_dma_rx_reenable_irq(). Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://lore.kernel.org/r/20230412145053.114847-3-biju.das.jz@bp.renesas.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20tty: serial: sh-sci: Add RZ/G2L SCIFA DMA tx supportBiju Das
SCIFA IP on RZ/G2L SoC has the same signal for both interrupt and DMA transfer request. Setting DMARS register for DMA transfer makes the signal to work as a DMA transfer request signal and subsequent interrupt requests to the interrupt controller are masked. Similarly clearing DMARS register makes signal to work as interrupt signal and subsequent interrupt requests to the interrupt controller are unmasked. Add SCIFA DMA tx support for RZ/G2L alike SoCs by disabling TXI line interrupt and setting DMARS registers by DMA api for DMA transfer request. Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://lore.kernel.org/r/20230412145053.114847-2-biju.das.jz@bp.renesas.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20serial: max310x: fix IO data corruption in batched operationsJan Kundrát
After upgrading from 5.16 to 6.1, our board with a MAX14830 started producing lots of garbage data over UART. Bisection pointed out commit 285e76fc049c as the culprit. That patch tried to replace hand-written code which I added in 2b4bac48c1084 ("serial: max310x: Use batched reads when reasonably safe") with the generic regmap infrastructure for batched operations. Unfortunately, the `regmap_raw_read` and `regmap_raw_write` which were used are actually functions which perform IO over *multiple* registers. That's not what is needed for accessing these Tx/Rx FIFOs; the appropriate functions are the `_noinc_` versions, not the `_raw_` ones. Fix this regression by using `regmap_noinc_read()` and `regmap_noinc_write()` along with the necessary `regmap_config` setup; with this patch in place, our board communicates happily again. Since our board uses SPI for talking to this chip, the I2C part is completely untested. Fixes: 285e76fc049c ("serial: max310x: use regmap methods for SPI batch operations") Cc: stable@vger.kernel.org Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Jan Kundrát <jan.kundrat@cesnet.cz> Link: https://lore.kernel.org/r/79db8e82aadb0e174bc82b9996423c3503c8fb37.1680732084.git.jan.kundrat@cesnet.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20serial: core: Disable uart_start() on uart_remove_one_port()Tony Lindgren
While rebinding a uart device in a loop I noticed we may see a tx related race on uart_remove_one_port(): uart_write from n_tty_write n_tty_write from file_tty_write.constprop.0 file_tty_write.constprop.0 from vfs_write vfs_write from ksys_write ksys_write from ret_fast_syscall Let's disallow tx on port->UPF_DEAD. This flag gets set before we start tearing down the port in uart_remove_one_port(). Signed-off-by: Tony Lindgren <tony@atomide.com> Link: https://lore.kernel.org/r/20230419115423.59957-1-tony@atomide.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20serial: 8250: Reinit port->pm on port specific driver unbindTony Lindgren
When we unbind a serial port hardware specific 8250 driver, the generic serial8250 driver takes over the port. After that we see an oops about 10 seconds later. This can produce the following at least on some TI SoCs: Unhandled fault: imprecise external abort (0x1406) Internal error: : 1406 [#1] SMP ARM Turns out that we may still have the serial port hardware specific driver port->pm in use, and serial8250_pm() tries to call it after the port specific driver is gone: serial8250_pm [8250_base] from uart_change_pm+0x54/0x8c [serial_base] uart_change_pm [serial_base] from uart_hangup+0x154/0x198 [serial_base] uart_hangup [serial_base] from __tty_hangup.part.0+0x328/0x37c __tty_hangup.part.0 from disassociate_ctty+0x154/0x20c disassociate_ctty from do_exit+0x744/0xaac do_exit from do_group_exit+0x40/0x8c do_group_exit from __wake_up_parent+0x0/0x1c Let's fix the issue by calling serial8250_set_defaults() in serial8250_unregister_port(). This will set the port back to using the serial8250 default functions, and sets the port->pm to point to serial8250_pm. Signed-off-by: Tony Lindgren <tony@atomide.com> Link: https://lore.kernel.org/r/20230418101407.12403-1-tony@atomide.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20serial: 8250: Add missing wakeup event reportingFlorian Fainelli
An 8250 UART configured as a wake-up source would not have reported itself through sysfs as being the source of wake-up, correct that. Fixes: b3b708fa2780 ("wake up from a serial port") Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/20230414170241.2016255-1-f.fainelli@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20tty: serial: fsl_lpuart: use UARTMODIR register bits for lpuart32 platformSherry Sun
For lpuart32 platforms, UARTMODIR register is used instead of UARTMODEM. So here should configure the corresponding UARTMODIR register bits to avoid confusion. Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Sherry Sun <sherry.sun@nxp.com> Link: https://lore.kernel.org/r/20230414022111.20896-1-sherry.sun@nxp.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20tty: serial: fsl_lpuart: adjust buffer length to the intended sizeShenwei Wang
Based on the fls function definition provided below, we should not subtract 1 to obtain the correct buffer length: fls(0) = 0, fls(1) = 1, fls(0x80000000) = 32. Fixes: 5887ad43ee02 ("tty: serial: fsl_lpuart: Use cyclic DMA for Rx") Signed-off-by: Shenwei Wang <shenwei.wang@nxp.com> Link: https://lore.kernel.org/r/20230410195555.1003900-1-shenwei.wang@nxp.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20serial: fix TIOCSRS485 lockingJohan Hovold
The RS485 multipoint addressing support for some reason added a new ADDRB termios cflag which is (only!) updated from one of the RS485 ioctls. Make sure to take the termios rw semaphore for the right ioctl (i.e. set, not get). Fixes: ae50bb275283 ("serial: take termios_rwsem for ->rs485_config() & pass termios as param") Cc: stable@vger.kernel.org # 6.0 Cc: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20230412124811.11217-1-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20serial: make SiFive serial drivers depend on ARCH_ symbolsConor Dooley
As part of converting RISC-V SOC_FOO symbols to ARCH_FOO to match the use of such symbols on other architectures, convert the SiFive serial driver Kconfig entries from the SOC_ symbols to ARCH_ instead. Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20230406-carnival-aspirate-fcf69a30078c@spud Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20tty: synclink_gt: don't allocate and pass dummy flagsJiri Slaby (SUSE)
In synclinc_gt, the flag_buf is allocated, zeroed and passed to ldisc's receive_buf(). It is never written to, so it serves as a dummy buffer. That's unneeded because all ldiscs accept NULL as flags. That NULL resolves to the TTY_NORMAL flag. So drop all this nonsense. Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org> Link: https://lore.kernel.org/r/20230420093530.13133-1-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20tty: serial: simplify qcom_geni_serial_send_chunk_fifo()Jiri Slaby (SUSE)
* use memcpy() instead of the loop (removes c variable) * use remaining parameter directly (removes chunk variable) The code is simpler and easier to follow. Cc: Andy Gross <agross@kernel.org> Cc: Bjorn Andersson <andersson@kernel.org> Cc: Konrad Dybcio <konrad.dybcio@linaro.org> Cc: linux-arm-msm@vger.kernel.org Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org> Link: https://lore.kernel.org/r/20230420093514.13055-1-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20leds: pwm-multicolor: Simplify an error messageChristophe JAILLET
dev_err_probe() already display the error code. There is no need to duplicate it explicitly in the error message. While at it, add a missing \n at the end of the message. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/07d35e221faaa380fd11cd4597e42354c8eb350c.1681576017.git.christophe.jaillet@wanadoo.fr
2023-04-20tty: n_gsm: fix redundant assignment of gsm->encodingDaniel Starke
The function gsmld_open() contains a redundant assignment of gsm->encoding. The same value of GSM_ADV_OPT is already assigned to it during the initialization of the struct in gsm_alloc_mux() a few lines earlier. Fix this by removing the redundant second assignment of gsm->encoding in gsmld_open(). Fixes: e1eaea46bb40 ("tty: n_gsm line discipline") Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Daniel Starke <daniel.starke@siemens.com> Link: https://lore.kernel.org/r/20230420085017.7314-1-daniel.starke@siemens.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20Merge branch 'for-next/misc' into for-next/coreWill Deacon
* for-next/misc: arm64: kexec: include reboot.h arm64: delete dead code in this_cpu_set_vectors() arm64: kernel: Fix kernel warning when nokaslr is passed to commandline arm64: kgdb: Set PSTATE.SS to 1 to re-enable single-step arm64/sme: Fix some comments of ARM SME arm64/signal: Alloc tpidr2 sigframe after checking system_supports_tpidr2() arm64/signal: Use system_supports_tpidr2() to check TPIDR2 arm64: compat: Remove defines now in asm-generic arm64: kexec: remove unnecessary (void*) conversions arm64: armv8_deprecated: remove unnecessary (void*) conversions firmware: arm_sdei: Fix sleep from invalid context BUG
2023-04-20i2c: designware: Add doorbell support for MendocinoMario Limonciello
Mendocino and later platform don't use the platform feature mailbox for communication for I2C arbitration, they rely upon ringing a doorbell. Detect the platform by the device ID of the root port and choose the appropriate method. Link: https://lore.kernel.org/linux-i2c/20220916131854.687371-3-jsd@semihalf.com/ Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Reviewed-by: Mark Hasemeyer <markhas@chromium.org> Tested-by: Mark Hasemeyer <markhas@chromium.org> Acked-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-04-20i2c: designware: Use PCI PSP driver for communicationMario Limonciello
Currently the PSP semaphore communication base address is discovered by using an MSR that is not architecturally guaranteed for future platforms. Also the mailbox that is utilized for communication with the PSP may have other consumers in the kernel, so it's better to make all communication go through a single driver. Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Reviewed-by: Mark Hasemeyer <markhas@chromium.org> Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Tested-by: Mark Hasemeyer <markhas@chromium.org> Acked-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-04-20leds: rgb: leds-qcom-lpg: Add support for PMK8550 PWMAnjelique Melendez
Add support for pmk8550 compatible and lpg_data. Signed-off-by: Anjelique Melendez <quic_amelende@quicinc.com> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230407223849.17623-4-quic_amelende@quicinc.com
2023-04-20leds: rgb: leds-qcom-lpg: Add support for high resolution PWMAnjelique Melendez
Certain PMICs like PMK8550 have a high resolution PWM module which can support from 8-bit to 15-bit PWM. Add support for it. Signed-off-by: Anjelique Melendez <quic_amelende@quicinc.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230407223849.17623-3-quic_amelende@quicinc.com
2023-04-20wifi: iwlwifi: mvm: fix RFKILL report when driver is going downAvraham Stern
When CSME takes ownership, the driver sets RFKILL on, and this triggers driver unload and sending the confirmation SAP message. However, when IWL_MVM_MEI_REPORT_RFKILL is set, RFKILL was not reported and as a result, the driver did not confirm the ownership transition. Fix it. Signed-off-by: Avraham Stern <avraham.stern@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230418122405.29ac3cd3df73.I96b32bc274bfe1e3871e54d3fa29c7ac4f40446f@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-04-20wifi: iwlwifi: mei: re-ask for ownership after it was taken by CSMEAvraham Stern
When the host disconnects from the AP CSME takes ownership right away. Since the driver never asks for ownership again wifi is left in rfkill until CSME releases the NIC, although in many cases the host could re-connect shortly after the disconnection. To allow the host to recover from occasional disconnection, re-ask for ownership to let the host connect again. Allow one minute before re-asking for ownership to avoid too frequent ownership transitions. Signed-off-by: Avraham Stern <avraham.stern@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230418122405.a6c6ebc48f2d.I8a17003b86e71b3567521cc69864b9cbe9553ea9@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-04-20wifi: iwlwifi: mei: make mei filtered scan more aggressiveAvraham Stern
When mei filtered scan is performed, it must find the AP on the first scan, otherwise CSME will take the ownership of the NIC. Make this scan more aggressive by scanning the channel the AP is supposed to be on (as reported by CSME) several times. Signed-off-by: Avraham Stern <avraham.stern@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230418122405.47e383b10b18.I14340a118acdb19ecb7214e7ff413054c77bd99c@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-04-20wifi: iwlwifi: modify scan request and results when in link protectionAvraham Stern
When CSME is connected and has link protection set, the driver must connect to the same AP CSME is connected to. When in link protection, modify scan request parameters to include only the channel of the AP CSME is connected to and scan for the same SSID. In addition, filter the scan results to include only results from the same AP. This will make sure the driver will connect to the same AP and will do it fast enough to keep the session alive. Signed-off-by: Avraham Stern <avraham.stern@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230418122405.c1b55de3d704.I3895eebe18b3b672607695c887d728e113fc85ec@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-04-20wifi: iwlwifi: mvm: enable support for MLO APIsGregory Greenman
Enable driver's support for MLO APIs to unlock this functionality. Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Link: https://lore.kernel.org/r/20230418122405.0ae0dd6f0481.Iec993cf0f28eacb2483fb9d1e755b0b2fd62e163@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-04-20wifi: iwlwifi: mvm: prefer RCU_INIT_POINTER()Johannes Berg
For constant values we don't need rcu_assign_pointer(), use RCU_INIT_POINTER() instead. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230418122405.7b400d21a27f.Iccdef9d777677390a9881c88b06c0ed13a83d978@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-04-20wifi: iwlwifi: mvm: fix potential memory leakJohannes Berg
If we do get multiple notifications from firmware, then we might have allocated 'notif', but don't free it. Fix that by checking for duplicates before allocation. Fixes: 4da46a06d443 ("wifi: iwlwifi: mvm: Add support for wowlan info notification") Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230418122405.116758321cc4.I8bdbcbb38c89ac637eaa20dda58fa9165b25893a@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-04-20wifi: iwlwifi: fw: fix argument to efi.get_variableAlon Giladi
We should pass the newly allocated data to fill. Signed-off-by: Alon Giladi <alon.giladi@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230418122405.aaa6d8874442.I734841c71aad9564cb22c50f2737aaff489fadaf@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-04-20wifi: iwlwifi: mvm: fix MIC removal confusionJohannes Berg
The RADA/firmware collaborate on MIC stripping in the following way: - the firmware fills the IWL_RX_MPDU_MFLG1_MIC_CRC_LEN_MASK value for how many words need to be removed at the end of the frame, CRC and, if decryption was done, MIC - if the RADA is active, it will - remove that much from the end of the frame - zero the value in IWL_RX_MPDU_MFLG1_MIC_CRC_LEN_MASK As a consequence, the only thing the driver should need to do is to - unconditionally tell mac80211 that the MIC was removed if decryption was already done - remove as much as IWL_RX_MPDU_MFLG1_MIC_CRC_LEN_MASK says at the end of the frame, since either RADA did it and then the value is 0, or RADA was disabled and then the value is whatever should be removed to strip both CRC & MIC However, all this code was historically grown and getting a bit confused. Originally, we were indicating that the MIC was not stripped, which is the version of the code upstreamed in commit 780e87c29e77 ("iwlwifi: mvm: add 9000 series RX processing") which indicated RX_FLAG_DECRYPTED in iwl_mvm_rx_crypto(). We later had a commit to change that to also indicate that the MIC was stripped, adding RX_FLAG_MIC_STRIPPED. However, this was then "fixed" later to only do that conditionally on RADA being enabled, since otherwise RADA didn't strip the MIC bytes yet. At the time, we were also always including the FCS if the RADA was not enabled, so that was still broken wrt. the FCS if the RADA isn't enabled - but that's a pretty rare case. Notably though, it does happen for management frames, where we do need to remove the MIC and CRC but the RADA is disabled. Later, in commit 40a0b38d7a7f ("iwlwifi: mvm: Fix calculation of frame length"), we changed this again, upstream this was just a single commit, but internally it was split into first the correct commit and then an additional fix that reduced the number of bytes that are removed by crypt_len. Note that this is clearly wrong since crypt_len indicates the length of the PN header (always 8), not the length of the MIC (8 or 16 depending on algorithm). However, this additional fix mostly canceled the other bugs, apart from the confusion about the size of the MIC. To fix this correctly, remove all those additional workarounds. We really should always indicate to mac80211 the MIC was stripped (it cannot use it anyway if decryption was already done), and also always actually remove it and the CRC regardless of the RADA being enabled or not. That's simple though, the value indicated in the metadata is zeroed by the RADA if it's enabled and used the value, so there's no need to check if it's enabled or not. Notably then, this fixes the MIC size confusion, letting us receive GCMP-256 encrypted management frames correctly that would otherwise be reported to mac80211 8 bytes too short since the RADA is turned off for them, crypt_len is 8, but the MIC size is 16, so when we do the adjustment based on IWL_RX_MPDU_MFLG1_MIC_CRC_LEN_MASK (which indicates 20 bytes to remove) we remove 12 bytes but indicate then to mac80211 the MIC is still present, so mac80211 again removes the MIC of 16 bytes, for an overall removal of 28 rather than 20 bytes. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230418122405.81345b6ab0cd.Ibe0348defb6cce11c99929a1f049e60b5cfc150c@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-04-20wifi: iwlwifi: fw: fix memory leak in debugfsJohannes Berg
Fix a memory leak that occurs when reading the fw_info file all the way, since we return NULL indicating no more data, but don't free the status tracking object. Fixes: 36dfe9ac6e8b ("iwlwifi: dump api version in yaml format") Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230418122405.239e501b3b8d.I4268f87809ef91209cbcd748eee0863195e70fa2@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-04-20wifi: iwlwifi: Update support for b0 versionMukesh Sisodiya
Add support for B0 version of MAC of MR device Signed-off-by: Mukesh Sisodiya <mukesh.sisodiya@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230418122405.5dca1ea7a0cf.I87932e1e216a1940eeae8824071ecb777f4c034f@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-04-20firmware: stratix10-svc: Fix an NULL vs IS_ERR() bug in probeDan Carpenter
The svc_create_memory_pool() function returns error pointers. It never returns NULL. Fix the check. Fixes: 7ca5ce896524 ("firmware: add Intel Stratix10 service layer driver") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Link: https://lore.kernel.org/r/5f9a8cb4-5a4f-460b-9cdc-2fae6c5b7922@kili.mountain Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20media: radio-shark: Add endpoint checksAlan Stern
The syzbot fuzzer was able to provoke a WARNING from the radio-shark2 driver: ------------[ cut here ]------------ usb 1-1: BOGUS urb xfer, pipe 1 != type 3 WARNING: CPU: 0 PID: 3271 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed2/0x1880 drivers/usb/core/urb.c:504 Modules linked in: CPU: 0 PID: 3271 Comm: kworker/0:3 Not tainted 6.1.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 Workqueue: usb_hub_wq hub_event RIP: 0010:usb_submit_urb+0xed2/0x1880 drivers/usb/core/urb.c:504 Code: 7c 24 18 e8 00 36 ea fb 48 8b 7c 24 18 e8 36 1c 02 ff 41 89 d8 44 89 e1 4c 89 ea 48 89 c6 48 c7 c7 a0 b6 90 8a e8 9a 29 b8 03 <0f> 0b e9 58 f8 ff ff e8 d2 35 ea fb 48 81 c5 c0 05 00 00 e9 84 f7 RSP: 0018:ffffc90003876dd0 EFLAGS: 00010282 RAX: 0000000000000000 RBX: 0000000000000003 RCX: 0000000000000000 RDX: ffff8880750b0040 RSI: ffffffff816152b8 RDI: fffff5200070edac RBP: ffff8880172d81e0 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000080000000 R11: 0000000000000000 R12: 0000000000000001 R13: ffff8880285c5040 R14: 0000000000000002 R15: ffff888017158200 FS: 0000000000000000(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffe03235b90 CR3: 000000000bc8e000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> usb_start_wait_urb+0x101/0x4b0 drivers/usb/core/message.c:58 usb_bulk_msg+0x226/0x550 drivers/usb/core/message.c:387 shark_write_reg+0x1ff/0x2e0 drivers/media/radio/radio-shark2.c:88 ... The problem was caused by the fact that the driver does not check whether the endpoints it uses are actually present and have the appropriate types. This can be fixed by adding a simple check of these endpoints (and similarly for the radio-shark driver). Link: https://syzkaller.appspot.com/bug?extid=4b3f8190f6e13b3efd74 Reported-and-tested-by: syzbot+4b3f8190f6e13b3efd74@syzkaller.appspotmail.com Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/e2858ab4-4adf-46e5-bbf6-c56742034547@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20USB: sisusbvga: Add endpoint checksAlan Stern
The syzbot fuzzer was able to provoke a WARNING from the sisusbvga driver: ------------[ cut here ]------------ usb 1-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 1 PID: 26 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504 Modules linked in: CPU: 1 PID: 26 Comm: kworker/1:1 Not tainted 6.2.0-rc5-syzkaller-00199-g5af6ce704936 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/12/2023 Workqueue: usb_hub_wq hub_event RIP: 0010:usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504 Code: 7c 24 18 e8 6c 50 80 fb 48 8b 7c 24 18 e8 62 1a 01 ff 41 89 d8 44 89 e1 4c 89 ea 48 89 c6 48 c7 c7 60 b1 fa 8a e8 84 b0 be 03 <0f> 0b e9 58 f8 ff ff e8 3e 50 80 fb 48 81 c5 c0 05 00 00 e9 84 f7 RSP: 0018:ffffc90000a1ed18 EFLAGS: 00010282 RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000 RDX: ffff888012783a80 RSI: ffffffff816680ec RDI: fffff52000143d95 RBP: ffff888079020000 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000080000000 R11: 0000000000000000 R12: 0000000000000003 R13: ffff888017d33370 R14: 0000000000000003 R15: ffff888021213600 FS: 0000000000000000(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005592753a60b0 CR3: 0000000022899000 CR4: 00000000003506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> sisusb_bulkout_msg drivers/usb/misc/sisusbvga/sisusbvga.c:224 [inline] sisusb_send_bulk_msg.constprop.0+0x904/0x1230 drivers/usb/misc/sisusbvga/sisusbvga.c:379 sisusb_send_bridge_packet drivers/usb/misc/sisusbvga/sisusbvga.c:567 [inline] sisusb_do_init_gfxdevice drivers/usb/misc/sisusbvga/sisusbvga.c:2077 [inline] sisusb_init_gfxdevice+0x87b/0x4000 drivers/usb/misc/sisusbvga/sisusbvga.c:2177 sisusb_probe+0x9cd/0xbe2 drivers/usb/misc/sisusbvga/sisusbvga.c:2869 ... The problem was caused by the fact that the driver does not check whether the endpoints it uses are actually present and have the appropriate types. This can be fixed by adding a simple check of the endpoints. Link: https://syzkaller.appspot.com/bug?extid=23be03b56c5259385d79 Reported-and-tested-by: syzbot+23be03b56c5259385d79@syzkaller.appspotmail.com Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/48ef98f7-51ae-4f63-b8d3-0ef2004bb60a@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20USB: core: Add routines for endpoint checks in old driversAlan Stern
Many of the older USB drivers in the Linux USB stack were written based simply on a vendor's device specification. They use the endpoint information in the spec and assume these endpoints will always be present, with the properties listed, in any device matching the given vendor and product IDs. While that may have been true back then, with spoofing and fuzzing it is not true any more. More and more we are finding that those old drivers need to perform at least a minimum of checking before they try to use any endpoint other than ep0. To make this checking as simple as possible, we now add a couple of utility routines to the USB core. usb_check_bulk_endpoints() and usb_check_int_endpoints() take an interface pointer together with a list of endpoint addresses (numbers and directions). They check that the interface's current alternate setting includes endpoints with those addresses and that each of these endpoints has the right type: bulk or interrupt, respectively. Although we already have usb_find_common_endpoints() and related routines meant for a similar purpose, they are not well suited for this kind of checking. Those routines find endpoints of various kinds, but only one (either the first or the last) of each kind, and they don't verify that the endpoints' addresses agree with what the caller expects. In theory the new routines could be more general: They could take a particular altsetting as their argument instead of always using the interface's current altsetting. In practice I think this won't matter too much; multiple altsettings tend to be used for transferring media (audio or visual) over isochronous endpoints, not bulk or interrupt. Drivers for such devices will generally require more sophisticated checking than these simplistic routines provide. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/dd2c8e8c-2c87-44ea-ba17-c64b97e201c9@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20firmware_loader: rework crypto dependenciesArnd Bergmann
The crypto dependencies for the firmwware loader are incomplete, in particular a built-in FW_LOADER fails to link against a modular crypto hash driver: ld.lld: error: undefined symbol: crypto_alloc_shash ld.lld: error: undefined symbol: crypto_shash_digest ld.lld: error: undefined symbol: crypto_destroy_tfm >>> referenced by main.c >>> drivers/base/firmware_loader/main.o:(fw_log_firmware_info) in archive vmlinux.a Rework this to use the usual 'select' from the driver module, to respect the built-in vs module dependencies, and add a more verbose crypto dependency to the debug option to prevent configurations that lead to a link failure. Fixes: 02fe26f25325 ("firmware_loader: Add debug message with checksum for FW file") Reviewed-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> Acked-by: Herbert Xu <herbert@gondor.apana.org.au> Acked-by: Luis Chamberlain <mcgrof@kernel.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20230414080329.76176-1-arnd@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20firmware_loader: Strip off \n from customized pathFlorian Fainelli
Having helped an user recently figure out why the customized path being specified was not taken into account landed on a subtle difference between using: echo "/xyz/firmware" > /sys/module/firmware_class/parameters/path which inserts an additional newline which is passed as is down to fw_get_filesystem_firmware() and ultimately kernel_read_file_from_path() and fails. Strip off \n from the customized firmware path such that users do not run into these hard to debug situations. Link: https://lore.kernel.org/all/20230402135423.3235-1-f.fainelli@gmail.com/ Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/20230413191757.1949088-1-f.fainelli@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20usb: dwc3: gadget: Stall and restart EP0 if host is unresponsiveWesley Cheng
It was observed that there are hosts that may complete pending SETUP transactions before the stop active transfers and controller halt occurs, leading to lingering endxfer commands on DEPs on subsequent pullup/gadget start iterations. dwc3_gadget_ep_disable name=ep8in flags=0x3009 direction=1 dwc3_gadget_ep_disable name=ep4in flags=1 direction=1 dwc3_gadget_ep_disable name=ep3out flags=1 direction=0 usb_gadget_disconnect deactivated=0 connected=0 ret=0 The sequence shows that the USB gadget disconnect (dwc3_gadget_pullup(0)) routine completed successfully, allowing for the USB gadget to proceed with a USB gadget connect. However, if this occurs the system runs into an issue where: BUG: spinlock already unlocked on CPU spin_bug+0x0 dwc3_remove_requests+0x278 dwc3_ep0_out_start+0xb0 __dwc3_gadget_start+0x25c This is due to the pending endxfers, leading to gadget start (w/o lock held) to execute the remove requests, which will unlock the dwc3 spinlock as part of giveback. To mitigate this, resolve the pending endxfers on the pullup disable path by re-locating the SETUP phase check after stop active transfers, since that is where the DWC3_EP_DELAY_STOP is potentially set. This also allows for handling of a host that may be unresponsive by using the completion timeout to trigger the stall and restart for EP0. Fixes: c96683798e27 ("usb: dwc3: ep0: Don't prepare beyond Setup stage") Cc: stable@vger.kernel.org Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com> Link: https://lore.kernel.org/r/20230413195742.11821-2-quic_wcheng@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20usb: dwc3: core: add support for disabling High-speed park modeStanley Chang
Setting the PARKMODE_DISABLE_HS bit in the DWC3_USB3_GUCTL1. When this bit is set to '1' all HS bus instances in park mode are disabled For some USB wifi devices, if enable this feature it will reduce the performance. Therefore, add an option for disabling HS park mode by device-tree. In Synopsys's dwc3 data book: In a few high speed devices when an IN request is sent within 900ns of the ACK of the previous packet, these devices send a NAK. When connected to these devices, if required, the software can disable the park mode if you see performance drop in your system. When park mode is disabled, pipelining of multiple packet is disabled and instead one packet at a time is requested by the scheduler. This allows up to 12 NAKs in a micro-frame and improves performance of these slow devices. Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Signed-off-by: Stanley Chang <stanley_chang@realtek.com> Link: https://lore.kernel.org/r/20230419020044.15475-1-stanley_chang@realtek.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20usb: mtu3: add optional clock xhci_ck and frmcnt_ckChunfeng Yun
Add optional clock 'xhci_ck' which is usually the same as sys_ck, but some SoC use two separated clocks when the controller supports dual role mode; Add optional clock 'frmcnt_ck' used on 4nm or advanced process SoC. Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com> Link: https://lore.kernel.org/r/20230417025203.18097-7-chunfeng.yun@mediatek.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20usb: mtu3: expose role-switch control to userspaceChunfeng Yun
The allow_userspace_control flag enables manual role switch from userspace, turn this feature on like several other USB DRD controller drivers. Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com> Link: https://lore.kernel.org/r/20230417025203.18097-5-chunfeng.yun@mediatek.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20usb: mtu3: unlock @mtu->lock just before giving back requestChunfeng Yun
No need unlock @mtu->lock when unmap request, unlock it just before giving back request, due to we do not lock this spinlock when map the request. Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com> Link: https://lore.kernel.org/r/20230417025203.18097-4-chunfeng.yun@mediatek.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20usb: mtu3: fix kernel panic at qmu transfer done irq handlerChunfeng Yun
When handle qmu transfer irq, it will unlock @mtu->lock before give back request, if another thread handle disconnect event at the same time, and try to disable ep, it may lock @mtu->lock and free qmu ring, then qmu irq hanlder may get a NULL gpd, avoid the KE by checking gpd's value before handling it. e.g. qmu done irq on cpu0 thread running on cpu1 qmu_done_tx() handle gpd [0] mtu3_requ_complete() mtu3_gadget_ep_disable() unlock @mtu->lock give back request lock @mtu->lock mtu3_ep_disable() mtu3_gpd_ring_free() unlock @mtu->lock lock @mtu->lock get next gpd [1] [1]: goto [0] to handle next gpd, and next gpd may be NULL. Fixes: 48e0d3735aa5 ("usb: mtu3: supports new QMU format") Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com> Link: https://lore.kernel.org/r/20230417025203.18097-3-chunfeng.yun@mediatek.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20usb: mtu3: use boolean return valueChunfeng Yun
Prefer to use boolean value due to gpd_ring_empty() return true or false. See "16) Function return values and names" in coding-style.rst Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com> Link: https://lore.kernel.org/r/20230417025203.18097-2-chunfeng.yun@mediatek.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20usb: mtu3: give back request when rx error happensChunfeng Yun
When the Rx enconnter errors, currently, only print error logs, that may cause class driver's RX halt, shall give back the request with error status meanwhile. Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com> Link: https://lore.kernel.org/r/20230417025203.18097-1-chunfeng.yun@mediatek.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20usb: chipidea: fix missing goto in `ci_hdrc_probe`Yinhao Hu
From the comment of ci_usb_phy_init, it returns an error code if usb_phy_init has failed, and it should do some clean up, not just return directly. Fix this by goto the error handling. Fixes: 74475ede784d ("usb: chipidea: move PHY operation to core") Reviewed-by: Dongliang Mu <dzm91@hust.edu.cn> Acked-by: Peter Chen <peter.chen@kernel.org> Signed-off-by: Yinhao Hu <dddddd@hust.edu.cn> Link: https://lore.kernel.org/r/20230412055852.971991-1-dddddd@hust.edu.cn Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit (git 2.34.1) at 2025-09-16 16:12:05 +0000