aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2024-06-20drm/xe/vf: Don't use register based TLB invalidation if VFMichal Wajdeczko1-0/+4
VF drivers can only use GuC-based TLB invalidation, as they don't have access to the related registers. However, VFs shouldn't need any explicit TLB invalidation before enabling CTB communication, as there will be an implicit GGTT TLB invalidation issued by the GuC itself as part of MMIO-based action handling. Signed-off-by: Michal Wajdeczko <[email protected]> Reviewed-by: Piotr Piórkowski <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-20drm/xe/vf: Don't support gtidle if VFMichal Wajdeczko1-0/+16
VF drivers can't access any of gtidle control registers as this functionality is owned by the PF driver. Signed-off-by: Michal Wajdeczko <[email protected]> Reviewed-by: Piotr Piórkowski <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-20drm/xe/vf: Don't initialize OA if VFMichal Wajdeczko1-0/+4
We don't support Observation Architecture on the VF device. Signed-off-by: Michal Wajdeczko <[email protected]> Cc: Rodrigo Vivi <[email protected]> Cc: Ashutosh Dixit <[email protected]> Reviewed-by: Ashutosh Dixit <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-20drm/xe/vf: Don't change hwe IRQ masks if using memory IRQsMichal Wajdeczko1-0/+3
We currently do not support changing the engine interrupt enable mask on the per-engine basis when using memory based interrupts. Signed-off-by: Michal Wajdeczko <[email protected]> Reviewed-by: Piotr Piórkowski <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-20drm/xe/vf: Don't apply tile workarounds if VFMichal Wajdeczko1-0/+4
The VF drivers can't apply any workarounds as they don't have access to related registers. Since xe_wa_apply_tile_workarounds() function is not using RTP yet, we have to add early return. Signed-off-by: Michal Wajdeczko <[email protected]> Cc: Matt Roper <[email protected]> Reviewed-by: Piotr Piórkowski <[email protected]> Reviewed-by: Matt Roper <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-20drm/xe/vf: Don't run any save-restore RTP actions if VFMichal Wajdeczko1-0/+4
There are no RTP save-restore actions applicable for VFs on current platforms. If any future platform will require some, we will need to update the RTP framework to support VF_READY or VF_ONLY actions. In the meantime, just skip all actions if we are running as VF driver. Signed-off-by: Michal Wajdeczko <[email protected]> Cc: Lucas De Marchi <[email protected]> Cc: Matt Roper <[email protected]> Reviewed-by: Piotr Piórkowski <[email protected]> Reviewed-by: Matt Roper <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-20drm/xe/vf: Disable features that do not apply to VFsMichal Wajdeczko1-0/+13
We already maintain several flags that control the availability of features on a given device. Disable features, like PCODE or GuC PC or GSC, that do not apply to a VF device. Signed-off-by: Michal Wajdeczko <[email protected]> Cc: Piotr Piórkowski <[email protected]> Reviewed-by: Piotr Piórkowski <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-20x86/kconfig: Add as-instr64 macro to properly evaluate AS_WRUSSMasahiro Yamada2-2/+3
Some instructions are only available on the 64-bit architecture. Bi-arch compilers that default to -m32 need the explicit -m64 option to evaluate them properly. Fixes: 18e66b695e78 ("x86/shstk: Add Kconfig option for shadow stack") Closes: https://lore.kernel.org/all/[email protected]/ Reported-by: Dmitry Safonov <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Tested-by: Dmitry Safonov <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-06-20cpufreq: update to sysfs_emit() for safer buffer handlingPerry Yuan1-19/+18
Replace sprintf() and scnprintf() with sysfs_emit() and sysfs_emit_at() in the cpufreq core. This ensures safer buffer handling and consistency with sysfs interfaces. Update show_scaling_available_governors() and related functions for compliance with the new API. Signed-off-by: Perry Yuan <[email protected]> Reviewed-by: Mario Limonciello <[email protected]> Link: https://patch.msgid.link/[email protected] [ rjw: Changelog edits ] Signed-off-by: Rafael J. Wysocki <[email protected]>
2024-06-20KVM: arm64: nVHE: Support CONFIG_CFI_CLANG at EL2Pierre-Clément Tosi3-4/+18
The compiler implements kCFI by adding type information (u32) above every function that might be indirectly called and, whenever a function pointer is called, injects a read-and-compare of that u32 against the value corresponding to the expected type. In case of a mismatch, a BRK instruction gets executed. When the hypervisor triggers such an exception in nVHE, it panics and triggers and exception return to EL1. Therefore, teach nvhe_hyp_panic_handler() to detect kCFI errors from the ESR and report them. If necessary, remind the user that EL2 kCFI is not affected by CONFIG_CFI_PERMISSIVE. Pass $(CC_FLAGS_CFI) to the compiler when building the nVHE hyp code. Use SYM_TYPED_FUNC_START() for __pkvm_init_switch_pgd, as nVHE can't call it directly and must use a PA function pointer from C (because it is part of the idmap page), which would trigger a kCFI failure if the type ID wasn't present. Signed-off-by: Pierre-Clément Tosi <[email protected]> Acked-by: Will Deacon <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Oliver Upton <[email protected]>
2024-06-20KVM: arm64: Introduce print_nvhe_hyp_panic helperPierre-Clément Tosi1-4/+8
Add a helper to display a panic banner soon to also be used for kCFI failures, to ensure that we remain consistent. Signed-off-by: Pierre-Clément Tosi <[email protected]> Acked-by: Will Deacon <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Oliver Upton <[email protected]>
2024-06-20arm64: Introduce esr_brk_comment, esr_is_cfi_brkPierre-Clément Tosi4-9/+16
As it is already used in two places, move esr_comment() to a header for re-use, with a clearer name. Introduce esr_is_cfi_brk() to detect kCFI BRK syndromes, currently used by early_brk64() but soon to also be used by hypervisor code. Signed-off-by: Pierre-Clément Tosi <[email protected]> Acked-by: Will Deacon <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Oliver Upton <[email protected]>
2024-06-20KVM: arm64: VHE: Mark __hyp_call_panic __noreturnPierre-Clément Tosi1-2/+1
Given that the sole purpose of __hyp_call_panic() is to call panic(), a __noreturn function, give it the __noreturn attribute, removing the need for its caller to use unreachable(). Signed-off-by: Pierre-Clément Tosi <[email protected]> Acked-by: Will Deacon <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Oliver Upton <[email protected]>
2024-06-20KVM: arm64: nVHE: gen-hyprel: Skip R_AARCH64_ABS32Pierre-Clément Tosi1-0/+6
Ignore R_AARCH64_ABS32 relocations, instead of panicking, when emitting the relocation table of the hypervisor. The toolchain might produce them when generating function calls with kCFI to represent the 32-bit type ID which can then be resolved across compilation units at link time. These are NOT actual 32-bit addresses and are therefore not needed in the final (runtime) relocation table (which is unlikely to use 32-bit absolute addresses for arm64 anyway). Signed-off-by: Pierre-Clément Tosi <[email protected]> Acked-by: Will Deacon <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Oliver Upton <[email protected]>
2024-06-20KVM: arm64: nVHE: Simplify invalid_host_el2_vectPierre-Clément Tosi1-6/+0
The invalid_host_el2_vect macro is used by EL2{t,h} handlers in nVHE *host* context, which should never run with a guest context loaded. Therefore, remove the superfluous vCPU context check and branch unconditionally to hyp_panic. Signed-off-by: Pierre-Clément Tosi <[email protected]> Acked-by: Will Deacon <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Oliver Upton <[email protected]>
2024-06-20KVM: arm64: Fix __pkvm_init_switch_pgd call ABIPierre-Clément Tosi3-15/+17
Fix the mismatch between the (incorrect) C signature, C call site, and asm implementation by aligning all three on an API passing the parameters (pgd and SP) separately, instead of as a bundled struct. Remove the now unnecessary memory accesses while the MMU is off from the asm, which simplifies the C caller (as it does not need to convert a VA struct pointer to PA) and makes the code slightly more robust by offsetting the struct fields from C and properly expressing the call to the C compiler (e.g. type checker and kCFI). Fixes: f320bc742bc2 ("KVM: arm64: Prepare the creation of s1 mappings at EL2") Signed-off-by: Pierre-Clément Tosi <[email protected]> Acked-by: Will Deacon <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Oliver Upton <[email protected]>
2024-06-20KVM: arm64: Fix clobbered ELR in sync abort/SErrorPierre-Clément Tosi3-2/+12
When the hypervisor receives a SError or synchronous exception (EL2h) while running with the __kvm_hyp_vector and if ELR_EL2 doesn't point to an extable entry, it panics indirectly by overwriting ELR with the address of a panic handler in order for the asm routine it returns to to ERET into the handler. However, this clobbers ELR_EL2 for the handler itself. As a result, hyp_panic(), when retrieving what it believes to be the PC where the exception happened, actually ends up reading the address of the panic handler that called it! This results in an erroneous and confusing panic message where the source of any synchronous exception (e.g. BUG() or kCFI) appears to be __guest_exit_panic, making it hard to locate the actual BRK instruction. Therefore, store the original ELR_EL2 in the per-CPU kvm_hyp_ctxt and point the sysreg to a routine that first restores it to its previous value before running __guest_exit_panic. Fixes: 7db21530479f ("KVM: arm64: Restore hyp when panicking in guest context") Signed-off-by: Pierre-Clément Tosi <[email protected]> Acked-by: Will Deacon <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Oliver Upton <[email protected]>
2024-06-20kselftest: devices: Add of-fullname-regex propertyNícolas F. R. A. Prado2-0/+28
Introduce a new 'of-fullname-regex' property that takes a regular expression and matches against the OF_FULLNAME property. It allows matching controllers that don't have a unique DT address across sibling controllers, and thus dt-mmio can't be used. One particular example of where this is needed is on MT8195 which has multiple USB controllers described by two level deep nodes and using the ranges property: ssusb2: usb@112a1000 { reg = <0 0x112a1000 0 0x2dff>, <0 0x112a3e00 0 0x0100>; ranges = <0 0 0 0x112a0000 0 0x3f00>; xhci2: usb@0 { Signed-off-by: Nícolas F. R. A. Prado <[email protected]> Link: https://lore.kernel.org/r/20240613-kselftest-discoverable-probe-mt8195-kci-v1-2-7b396a9b032d@collabora.com Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-06-20kselftest: devices: Allow specifying boards directory through parameterNícolas F. R. A. Prado1-1/+12
Add support for a --boards-dir parameter through which the directory in which the board files will be searched for can be specified. The 'boards' subdirectory is still used as default when the parameter is not specified. This allows more easily running the test with board files supplied by an external repository like https://github.com/kernelci/platform-test-parameters. Signed-off-by: Nícolas F. R. A. Prado <[email protected]> Link: https://lore.kernel.org/r/20240613-kselftest-discoverable-probe-mt8195-kci-v1-1-7b396a9b032d@collabora.com Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-06-20arm64: dts: amlogic: Used onboard usb hub reset on odroid n2Anand Moon1-12/+24
On Odroid n2/n2+ previously use gpio-hog to reset the usb hub, switch to used on-board usb hub reset to enable the usb hub and enable power to hub. Signed-off-by: Anand Moon <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-06-20dt-bindings: usb: Add the binding example for the Genesys Logic GL3523 hubAnand Moon1-5/+55
Add the binding example for the USB3.1 Genesys Logic GL3523 integrates with USB 3.1 Gen 1 Super Speed and USB 2.0 High-Speed hub. For onboard hub controllers that support USB 3.x and USB 2.0 hubs with shared resets and power supplies, this property is used to identify the hubs with which these are shared. GL3523 has built-in 5V to 3.3V and 5V to 1.2V regulators, which serves power to the USB HUB, it uses 5V power regulator. Update the peer-hub description. Reviewed-by: Conor Dooley <[email protected]> Signed-off-by: Anand Moon <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-06-20usb: gadget: aspeed_udc: fix device address configurationJeremy Kerr1-2/+2
In the aspeed UDC setup, we configure the UDC hardware with the assigned USB device address. However, we have an off-by-one in the bitmask, so we're only setting the lower 6 bits of the address (USB addresses being 7 bits, and the hardware bitmask being bits 0:6). This means that device enumeration fails if the assigned address is greater than 64: [ 344.607255] usb 1-1: new high-speed USB device number 63 using ehci-platform [ 344.808459] usb 1-1: New USB device found, idVendor=cc00, idProduct=cc00, bcdDevice= 6.10 [ 344.817684] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 344.825671] usb 1-1: Product: Test device [ 344.831075] usb 1-1: Manufacturer: Test vendor [ 344.836335] usb 1-1: SerialNumber: 00 [ 349.917181] usb 1-1: USB disconnect, device number 63 [ 352.036775] usb 1-1: new high-speed USB device number 64 using ehci-platform [ 352.249432] usb 1-1: device descriptor read/all, error -71 [ 352.696740] usb 1-1: new high-speed USB device number 65 using ehci-platform [ 352.909431] usb 1-1: device descriptor read/all, error -71 Use the correct mask of 0x7f (rather than 0x3f), and generate this through the GENMASK macro, so we have numbers that correspond exactly to the hardware register definition. Fixes: 055276c13205 ("usb: gadget: add Aspeed ast2600 udc driver") Cc: [email protected] Reviewed-by: Neal Liu <[email protected]> Reviewed-by: Andrew Jeffery <[email protected]> Signed-off-by: Jeremy Kerr <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-06-20usb: dwc3: core: remove lock of otg mode during gadget suspend/resume to ↵Meng Li1-6/+0
avoid deadlock When config CONFIG_USB_DWC3_DUAL_ROLE is selected, and trigger system to enter suspend status with below command: echo mem > /sys/power/state There will be a deadlock issue occurring. Detailed invoking path as below: dwc3_suspend_common() spin_lock_irqsave(&dwc->lock, flags); <-- 1st dwc3_gadget_suspend(dwc); dwc3_gadget_soft_disconnect(dwc); spin_lock_irqsave(&dwc->lock, flags); <-- 2nd This issue is exposed by commit c7ebd8149ee5 ("usb: dwc3: gadget: Fix NULL pointer dereference in dwc3_gadget_suspend") that removes the code of checking whether dwc->gadget_driver is NULL or not. It causes the following code is executed and deadlock occurs when trying to get the spinlock. In fact, the root cause is the commit 5265397f9442("usb: dwc3: Remove DWC3 locking during gadget suspend/resume") that forgot to remove the lock of otg mode. So, remove the redundant lock of otg mode during gadget suspend/resume. Fixes: 5265397f9442 ("usb: dwc3: Remove DWC3 locking during gadget suspend/resume") Cc: Xu Yang <[email protected]> Cc: [email protected] Signed-off-by: Meng Li <[email protected]> Acked-by: Thinh Nguyen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-06-20usb: typec: ucsi: glink: fix child node release in probe functionJavier Carrasco1-1/+4
The device_for_each_child_node() macro requires explicit calls to fwnode_handle_put() in all early exits of the loop if the child node is not required outside. Otherwise, the child node's refcount is not decremented and the resource is not released. The current implementation of pmic_glink_ucsi_probe() makes use of the device_for_each_child_node(), but does not release the child node on early returns. Add the missing calls to fwnode_handle_put(). Cc: [email protected] Fixes: c6165ed2f425 ("usb: ucsi: glink: use the connector orientation GPIO to provide switch events") Signed-off-by: Javier Carrasco <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Heikki Krogerus <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-06-20backlight: Drop explicit initialization of struct i2c_device_id::driver_data ↵Uwe Kleine-König8-9/+12
to 0 These drivers don't use the driver_data member of struct i2c_device_id, so don't explicitly initialize this member. This prepares putting driver_data in an anonymous union which requires either no initialization or named designators. But it's also a nice cleanup on its own. While add it, also remove commas after the sentinel entries. Signed-off-by: Uwe Kleine-König <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2024-06-20usb: musb: da8xx: fix a resource leak in probe()Dan Carpenter1-2/+6
Call usb_phy_generic_unregister() if of_platform_populate() fails. Fixes: d6299b6efbf6 ("usb: musb: Add support of CPPI 4.1 DMA controller to DA8xx") Cc: stable <[email protected]> Signed-off-by: Dan Carpenter <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-06-20usb: typec: ucsi_acpi: Add LG Gram quirkDiogo Ivo1-0/+61
Some LG Gram laptops report a bogus connector change event after a GET_PDOS command for the partner's source PDOs, which disappears from the CCI after acknowledging the command. However, the subsequent GET_CONNECTOR_STATUS in ucsi_handle_connector_change() still reports this bogus change in bits 5 and 6, leading to the UCSI core re-checking the partner's source PDOs and thus to an infinite loop. Fix this by adding a quirk that signals when a potentially buggy GET_PDOS command is used, checks the status change report and clears it if it is a bogus event before sending it to the UCSI core. Signed-off-by: Diogo Ivo <[email protected]> Reviewed-by: Heikki Krogerus <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-06-20usb: ucsi: stm32: fix command completion handlingFabrice Gasnier1-4/+15
Sometimes errors are seen, when doing DR swap, like: [ 24.672481] ucsi-stm32g0-i2c 0-0035: UCSI_GET_PDOS failed (-5) [ 24.720188] ucsi-stm32g0-i2c 0-0035: ucsi_handle_connector_change: GET_CONNECTOR_STATUS failed (-5) There may be some race, which lead to read CCI, before the command complete flag is set, hence returning -EIO. Similar fix has been done also in ucsi_acpi [1]. In case of a spurious or otherwise delayed notification it is possible that CCI still reports the previous completion. The UCSI spec is aware of this and provides two completion bits in CCI, one for normal commands and one for acks. As acks and commands alternate the notification handler can determine if the completion bit is from the current command. To fix this add the ACK_PENDING bit for ucsi_stm32g0 and only complete commands if the completion bit matches. [1] https://lore.kernel.org/lkml/[email protected]/ Fixes: 72849d4fcee7 ("usb: typec: ucsi: stm32g0: add support for stm32g0 controller") Signed-off-by: Fabrice Gasnier <[email protected]> Link: https://lore.kernel.org/stable/20240612124656.2305603-1-fabrice.gasnier%40foss.st.com Cc: stable <[email protected]> Reviewed-by: Heikki Krogerus <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-06-20usb: atm: cxacru: fix endpoint checking in cxacru_bind()Nikita Zhandarovich1-0/+14
Syzbot is still reporting quite an old issue [1] that occurs due to incomplete checking of present usb endpoints. As such, wrong endpoints types may be used at urb sumbitting stage which in turn triggers a warning in usb_submit_urb(). Fix the issue by verifying that required endpoint types are present for both in and out endpoints, taking into account cmd endpoint type. Unfortunately, this patch has not been tested on real hardware. [1] Syzbot report: usb 1-1: BOGUS urb xfer, pipe 1 != type 3 WARNING: CPU: 0 PID: 8667 at drivers/usb/core/urb.c:502 usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502 Modules linked in: CPU: 0 PID: 8667 Comm: kworker/0:4 Not tainted 5.14.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: usb_hub_wq hub_event RIP: 0010:usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502 ... Call Trace: cxacru_cm+0x3c0/0x8e0 drivers/usb/atm/cxacru.c:649 cxacru_card_status+0x22/0xd0 drivers/usb/atm/cxacru.c:760 cxacru_bind+0x7ac/0x11a0 drivers/usb/atm/cxacru.c:1209 usbatm_usb_probe+0x321/0x1ae0 drivers/usb/atm/usbatm.c:1055 cxacru_usb_probe+0xdf/0x1e0 drivers/usb/atm/cxacru.c:1363 usb_probe_interface+0x315/0x7f0 drivers/usb/core/driver.c:396 call_driver_probe drivers/base/dd.c:517 [inline] really_probe+0x23c/0xcd0 drivers/base/dd.c:595 __driver_probe_device+0x338/0x4d0 drivers/base/dd.c:747 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:777 __device_attach_driver+0x20b/0x2f0 drivers/base/dd.c:894 bus_for_each_drv+0x15f/0x1e0 drivers/base/bus.c:427 __device_attach+0x228/0x4a0 drivers/base/dd.c:965 bus_probe_device+0x1e4/0x290 drivers/base/bus.c:487 device_add+0xc2f/0x2180 drivers/base/core.c:3354 usb_set_configuration+0x113a/0x1910 drivers/usb/core/message.c:2170 usb_generic_driver_probe+0xba/0x100 drivers/usb/core/generic.c:238 usb_probe_device+0xd9/0x2c0 drivers/usb/core/driver.c:293 Reported-and-tested-by: [email protected] Fixes: 902ffc3c707c ("USB: cxacru: Use a bulk/int URB to access the command endpoint") Cc: stable <[email protected]> Signed-off-by: Nikita Zhandarovich <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-06-20usb: gadget: printer: fix races against disableOliver Neukum1-10/+29
printer_read() and printer_write() guard against the race against disable() by checking the dev->interface flag, which in turn is guarded by a spinlock. These functions, however, drop the lock on multiple occasions. This means that the test has to be redone after reacquiring the lock and before doing IO. Add the tests. This also addresses CVE-2024-25741 Fixes: 7f2ca14d2f9b9 ("usb: gadget: function: printer: Interface is disabled and returns error") Cc: stable <[email protected]> Signed-off-by: Oliver Neukum <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-06-20usb: gadget: printer: SS+ supportOliver Neukum1-0/+1
We need to treat super speed plus as super speed, not the default, which is full speed. Signed-off-by: Oliver Neukum <[email protected]> Cc: stable <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-06-20usb: typec-mux: nb7vpq904m: broadcast typec state to next muxNeil Armstrong1-2/+22
In the Type-C graph, the nb7vpq904m retimer is in between the USB-C connector and the USB3/DP combo PHY, and this PHY also requires the USB-C mode events to properly set-up the SuperSpeed Lanes functions to setup USB3-only, USB3 + DP Altmode or DP Altmode only on the 4 lanes. Update the nb7vpq904m retimer to get an optional type-c mux on the next endpoint, and broadcast the received mode to it. Signed-off-by: Neil Armstrong <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Heikki Krogerus <[email protected]> Link: https://lore.kernel.org/r/20240606-topic-sm8x50-upstream-retimer-broadcast-mode-v2-4-c6f6eae479c3@linaro.org Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-06-20usb: typec-mux: ptn36502: broadcast typec state to next muxNeil Armstrong1-2/+22
In the Type-C graph, the ptn36502 retimer is in between the USB-C connector and the USB3/DP combo PHY, and this PHY also requires the USB-C mode events to properly set-up the SuperSpeed Lanes functions to setup USB3-only, USB3 + DP Altmode or DP Altmode only on the 4 lanes. Update the ptn36502 retimer to get an optional type-c mux on the next endpoint, and broadcast the received mode to it. Tested-by: Luca Weiss <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Reviewed-by: Heikki Krogerus <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Link: https://lore.kernel.org/r/20240606-topic-sm8x50-upstream-retimer-broadcast-mode-v2-3-c6f6eae479c3@linaro.org Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-06-20usb: typec-mux: nb7vpq904m: unregister typec switch on probe error and removeNeil Armstrong1-1/+6
Add the missing call to typec_switch_put() when probe fails and the nb7vpq904m_remove() call is called. Fixes: 348359e7c232 ("usb: typec: nb7vpq904m: Add an error handling path in nb7vpq904m_probe()") Signed-off-by: Neil Armstrong <[email protected]> Fixes: 88d8f3ac9c67 ("usb: typec: add support for the nb7vpq904m Type-C Linear Redriver") Reviewed-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Heikki Krogerus <[email protected]> Link: https://lore.kernel.org/r/20240606-topic-sm8x50-upstream-retimer-broadcast-mode-v2-2-c6f6eae479c3@linaro.org Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-06-20usb: typec-mux: ptn36502: unregister typec switch on probe error and removeNeil Armstrong1-2/+9
Add the missing call to typec_switch_put() when probe fails and the ptn36502_remove() call is called. Fixes: 8e99dc783648 ("usb: typec: add support for PTN36502 redriver") Signed-off-by: Neil Armstrong <[email protected]> Reviewed-by: Heikki Krogerus <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Link: https://lore.kernel.org/r/20240606-topic-sm8x50-upstream-retimer-broadcast-mode-v2-1-c6f6eae479c3@linaro.org Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-06-20usb: typec: ucsi: psy: Add support for the charge type propertyHeikki Krogerus2-0/+35
Adding support for the charge type Linux power supply class property (POWER_SUPPLY_PROP_CHARGE_TYPE) to the UCSI driver. That will make the charge type visible in the charge_type power supply class sysfs attribute file. UCSI has the charge type specified in the Battery Charging Status field of the response to the GET_CONNECTOR_STATUS command. Reviewed-by: Sebastian Reichel <[email protected]> Reviewed-by: Mario Limonciello <[email protected]> Signed-off-by: Heikki Krogerus <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-06-20usb: typec: ucsi: Changing the driver data type to voidHeikki Krogerus1-1/+1
Let's use the same data type as struct device. Signed-off-by: Heikki Krogerus <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-06-20dt-bindings: usb: gpio-sbu-mux: Add an entry for TMUXHS4212Parth Pancholi1-0/+1
Add a compatible entry for the TI TMUXHS4212 GPIO-based bidirectional 2:1 mux/1:2 demux which can be used for switching orientation of the SBU lines in USB Type-C applications. TMUXHS4212 datasheet: https://www.ti.com/lit/ds/symlink/tmuxhs4212.pdf Signed-off-by: Parth Pancholi <[email protected]> Acked-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Francesco Dolcini <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-06-20dt-bindings: usb: qcom,dwc3: Add SC8180X compatiblesBjorn Andersson1-0/+29
The SC8180X platform has two single port DWC3 instances and a two-port DWC3 instance. Add compatibles for these to the binding. Reviewed-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/20240610-sc8180x-dwc3-binding-compatible-v2-1-c7d5db9702a2@quicinc.com Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-06-20usb: typec: ucsi: don't retrieve PDOs if not supportedMark Pearson1-0/+4
On systems where the UCSI PDOs are not supported, the UCSI driver is giving an error message. This can cause users to believe there is a HW issue with their system when in fact it is working as designed. Check if PDO_DETAILS are supported as a feature before attempting to access PDO. If not supported return that zero PDOs are available. Tested on Lenovo L14 G5 AMD and confirmed with Lenovo FW team that PDOs are not supported on this platform. Suggested-by: Diogo Ivo <[email protected]> Suggested-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Mark Pearson <[email protected]> Reviewed-by: Heikki Krogerus <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-06-20usb: host: xhci-plat: Add support for XHCI_WRITE_64_HI_LODaehwan Jung1-0/+3
xHCI specification 5.1 "Register Conventions" states that 64 bit registers should be written in low-high order. All writing operations in xhci is done low-high order following the spec. Add a new quirk to support workaround for high-low order. Signed-off-by: Daehwan Jung <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-06-20xhci: Add a quirk for writing ERST in high-low orderDaehwan Jung2-1/+6
This quirk is for the controller that has a limitation in supporting separate ERSTBA_HI and ERSTBA_LO programming. It's supported when the ERSTBA is programmed ERSTBA_HI before ERSTBA_LO. That's because the internal initialization of event ring fetches the "Event Ring Segment Table Entry" based on the indication of ERSTBA_LO written. Signed-off-by: Daehwan Jung <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-06-20usb: dwc3: Support quirk for writing high-low orderDaehwan Jung1-1/+3
There's the limitation of Synopsys dwc3 controller with ERST programming in supporting separate ERSTBA_HI and ERSTBA_LO programming. It's supported when the ERSTBA is programmed ERSTBA_HI before ERSTBA_LO. But, writing operations in xHCI is done low-high order following xHCI spec. xHCI specification 5.1 "Register Conventions" states that 64 bit registers should be written in low-high order. Synopsys dwc3 needs workaround for high-low order. That's why adding new quirk is needed to support this. Signed-off-by: Daehwan Jung <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-06-20usb: typec: tipd: use min() to set tps6598x firmware packet sizeJavier Carrasco1-4/+1
Simplify the current firmware packet size check in the tps6598x implementation by means of a single call to min(), which is what the current code does in a more verbose, less elegant way. This patch fixes a cocci warning ("WARNING opportunity for min()"). Suggested-by: Julia Lawall <[email protected]> Signed-off-by: Javier Carrasco <[email protected]> Reviewed-by: Heikki Krogerus <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-06-20usb: typec: tipd: add error log to provide firmware name and sizeJavier Carrasco1-0/+4
The current error logs do not show the firmware name and size for the tps6598x. On the other hand, this information is provided for the tps25750. Both implementations have access to that information, and the existing message for the tps25750 can be used for the tps6598x without extra modifications. Signed-off-by: Javier Carrasco <[email protected]> Reviewed-by: Heikki Krogerus <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-06-20usb: typec: tipd: drop second firmware name readJavier Carrasco1-17/+7
tps_request_firmware() reads the firmware name and there is no need to repeat the action in the device-specific implementations of the firmware update mechanism. Provide the firmware name as a parameter in tps_request_firmware() to avoid repetitive operations in the device-specific implementations. Signed-off-by: Javier Carrasco <[email protected]> Reviewed-by: Heikki Krogerus <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-06-20Merge tag 'sound-6.10-rc5' of ↵Linus Torvalds9-11/+61
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound Pull sound fixes from Takashi Iwai: "Lots of small HD-audio quirks and fixes (mostly Realtek codec and Cirrus stuff). Also a small MIDI 2.0 fix and a fix for missing module description are included" * tag 'sound-6.10-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: ALSA: hda: cs35l56: Select SERIAL_MULTI_INSTANTIATE ALSA: hda/realtek: Add more codec ID to no shutup pins list sound/oss/dmasound: add missing MODULE_DESCRIPTION() macro ALSA: hda/realtek: Add quirk for Lenovo Yoga Pro 7 14ARP8 ALSA: hda/realtek: Enable headset mic on IdeaPad 330-17IKB 81DM ALSA: hda: tas2781: Component should be unbound before deconstruction ALSA: hda: cs35l41: Component should be unbound before deconstruction ALSA: hda: cs35l56: Component should be unbound before deconstruction ALSA/hda: intel-dsp-config: Document AVS as dsp_driver option ALSA: hda/realtek: Support Lenovo Thinkbook 13x Gen 4 ALSA: hda/realtek: Support Lenovo Thinkbook 16P Gen 5 ALSA: hda: cs35l41: Support Lenovo Thinkbook 13x Gen 4 ALSA: hda: cs35l41: Support Lenovo Thinkbook 16P Gen 5 ALSA: hda/realtek: Remove Framework Laptop 16 from quirks ALSA: hda/realtek: Limit mic boost on N14AP7 ALSA: hda/realtek: fix mute/micmute LEDs don't work for ProBook 445/465 G11. ALSA: seq: ump: Fix missing System Reset message handling ALSA: hda: cs35l41: Possible null pointer dereference in cs35l41_hda_unbind() ALSA: hda: cs35l56: Fix lifecycle of codec pointer
2024-06-20usb: typec: tcpm: use 'time_left' variable with wait_for_completion_timeout()Wolfram Sang1-4/+4
There is a confusing pattern in the kernel to use a variable named 'timeout' to store the result of wait_for_completion_timeout() causing patterns like: timeout = wait_for_completion_timeout(...) if (!timeout) return -ETIMEDOUT; with all kinds of permutations. Use 'time_left' as a variable to make the code self explaining. Signed-off-by: Wolfram Sang <[email protected]> Reviewed-by: Heikki Krogerus <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-06-20nvme-apple: add missing MODULE_DESCRIPTION()Jeff Johnson1-0/+1
make allmodconfig && make W=1 C=1 reports: WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/nvme/host/nvme-apple.o Add the missing invocation of the MODULE_DESCRIPTION() macro. Reviewed-by: Eric Curtin <[email protected]> Reviewed-by: Sven Peter <[email protected]> Reviewed-by: Sagi Grimberg <[email protected]> Signed-off-by: Jeff Johnson <[email protected]> Signed-off-by: Keith Busch <[email protected]>
2024-06-20usb: misc: Drop explicit initialization of struct i2c_device_id::driver_data ↵Uwe Kleine-König3-11/+11
to 0 These drivers don't use the driver_data member of struct i2c_device_id, so don't explicitly initialize this member. This prepares putting driver_data in an anonymous union which requires either no initialization or named designators. But it's also a nice cleanup on its own. Signed-off-by: Uwe Kleine-König <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.