Change the default value of spectre v2 in user mode to respect the
CONFIG_MITIGATION_SPECTRE_V2 config option.
Currently, user mode spectre v2 is set to auto
(SPECTRE_V2_USER_CMD_AUTO) by default, even if
CONFIG_MITIGATION_SPECTRE_V2 is disabled.
Set the spectre_v2 value to auto (SPECTRE_V2_USER_CMD_AUTO) if the
Spectre v2 config (CONFIG_MITIGATION_SPECTRE_V2) is enabled, otherwise
set the value to none (SPECTRE_V2_USER_CMD_NONE).
Important to say the command line argument "spectre_v2_user" overwrites
the default value in both cases.
When CONFIG_MITIGATION_SPECTRE_V2 is not set, users have the flexibility
to opt-in for specific mitigations independently. In this scenario,
setting spectre_v2= will not enable spectre_v2_user=, and command line
options spectre_v2_user and spectre_v2 are independent when
CONFIG_MITIGATION_SPECTRE_V2=n.
Signed-off-by: Breno Leitao <leitao@debian.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Reviewed-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Acked-by: Josh Poimboeuf <jpoimboe@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: David Kaplan <David.Kaplan@amd.com>
Link: https://lore.kernel.org/r/20241031-x86_bugs_last_v2-v2-2-b7ff1dab840e@debian.org
There is a helper function to check if SMT is available. Use this helper
instead of performing the check manually.
The helper function cpu_smt_possible() does exactly the same thing as
was being done manually inside spectre_v2_user_select_mitigation().
Specifically, it returns false if CONFIG_SMP is disabled, otherwise
it checks the cpu_smt_control global variable.
This change improves code consistency and reduces duplication.
No change in functionality intended.
Signed-off-by: Breno Leitao <leitao@debian.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Reviewed-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Cc: David Kaplan <David.Kaplan@amd.com>
Link: https://lore.kernel.org/r/20241031-x86_bugs_last_v2-v2-1-b7ff1dab840e@debian.org
In the interest of limiting the display dependencies on i915 core
headers, split out i915_gtt_view_types.h from i915_vma_types.h, and only
include the new header from intel_display_types.h.
Reuse the new header from xe compat code too, failing build if partial
view is used in display code.
Side note: Why would we ever have set enum i915_gtt_view_type values to
size of each type?! What an insane hack.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/bb31885c32dbddad76d634c6fdb98a73b546b42e.1740412806.git.jani.nikula@intel.com
With the primary goal of removing #include "i915_vma.h" from
intel_display_types.h, move intel_plane_ggtt_offset() to a proper
function in intel_atomic_plane.c. This reveals tons of implicit
dependencies all over the place that we pulled in via i915_vma.h. Fix
the fallout.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/70ac6d19518f355abf37ac8c4b0f1d18878be28c.1740412806.git.jani.nikula@intel.com
These result in a very small reduction in driver size, but at the cost
of more complex build and slightly harder to read code. In the case of
of_match_ptr() it also prevents use of PRP0001 ACPI based identification.
In this particular case we have a valid ACPI/PNP ID that should be used
in preference to PRP0001 but doesn't mean we should prevent that route.
With this done, drop unneeded of*.h inclusions and __maybe_unused markers.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20250225100838.362125-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Retpoline mitigation for spectre-v2 uses thunks for indirect branches. To
support this mitigation compilers add a CS prefix with
-mindirect-branch-cs-prefix. For an indirect branch in asm, this needs to
be added manually.
CS prefix is already being added to indirect branches in asm files, but not
in inline asm. Add CS prefix to CALL_NOSPEC for inline asm as well. There
is no JMP_NOSPEC for inline asm.
Reported-by: Josh Poimboeuf <jpoimboe@kernel.org>
Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: https://lore.kernel.org/r/20250228-call-nospec-v3-2-96599fed0f33@linux.intel.com
CALL_NOSPEC macro is used to generate Spectre-v2 mitigation friendly
indirect branches. At compile time the macro defaults to indirect branch,
and at runtime those can be patched to thunk based mitigations.
This approach is opposite of what is done for the rest of the kernel, where
the compile time default is to replace indirect calls with retpoline thunk
calls.
Make CALL_NOSPEC consistent with the rest of the kernel, default to
retpoline thunk at compile time when CONFIG_MITIGATION_RETPOLINE is
enabled.
Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: https://lore.kernel.org/r/20250228-call-nospec-v3-1-96599fed0f33@linux.intel.com
`cb_mutex` was introduced in commit 9e0894d070 ("platform/x86/amd/pmf:
Enable Custom BIOS Inputs for PMF-TA") to prevent conccurrent access for
BIOS inputs. It however isn't initialized and so on use it may lead to
a NULL pointer dereference.
Add code to initialize on probe and clean up on destroy.
Reported-by: Yijun Shen <Yijun.Shen@dell.com>
Cc: Richard Gong <richgong@amd.com>
Fixes: 9e0894d070 ("platform/x86/amd/pmf: Enable Custom BIOS Inputs for PMF-TA")
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Tested-By: Yijun Shen <Yijun_Shen@Dell.com>
Acked-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Link: https://lore.kernel.org/r/20250227170308.435862-1-superm1@kernel.org
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
On architectures where ARCH_HAS_SYNC_CORE_BEFORE_USERMODE
is not selected, sync_core_before_usermode() is a no-op.
In membarrier_mm_sync_core_before_usermode() the compiler does not
eliminate redundant branches and load of mm->membarrier_state
for this case as the atomic_read() cannot be optimized away.
Here's a snippet of the code generated for finish_task_switch() on powerpc
prior to this change:
1b786c: ld r26,2624(r30) # mm = rq->prev_mm;
.......
1b78c8: cmpdi cr7,r26,0
1b78cc: beq cr7,1b78e4 <finish_task_switch+0xd0>
1b78d0: ld r9,2312(r13) # current
1b78d4: ld r9,1888(r9) # current->mm
1b78d8: cmpd cr7,r26,r9
1b78dc: beq cr7,1b7a70 <finish_task_switch+0x25c>
1b78e0: hwsync
1b78e4: cmplwi cr7,r27,128
.......
1b7a70: lwz r9,176(r26) # atomic_read(&mm->membarrier_state)
1b7a74: b 1b78e0 <finish_task_switch+0xcc>
This was found while analyzing "perf c2c" reports on kernels prior
to commit c1753fd02a ("mm: move mm_count into its own cache line")
where mm_count was false sharing with membarrier_state.
There is a minor improvement in the size of finish_task_switch().
The following are results from bloat-o-meter for ppc64le:
GCC 7.5.0
---------
add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-32 (-32)
Function old new delta
finish_task_switch 884 852 -32
GCC 12.2.1
----------
add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-32 (-32)
Function old new delta
finish_task_switch.isra 852 820 -32
LLVM 17.0.6
-----------
add/remove: 0/0 grow/shrink: 0/2 up/down: 0/-36 (-36)
Function old new delta
rt_mutex_schedule 120 104 -16
finish_task_switch 792 772 -20
Results on aarch64:
GCC 14.1.1
----------
add/remove: 0/2 grow/shrink: 1/1 up/down: 4/-60 (-56)
Function old new delta
get_nohz_timer_target 352 356 +4
e843419@0b02_0000d7e7_408 8 - -8
e843419@01bb_000021d2_868 8 - -8
finish_task_switch.isra 592 548 -44
Signed-off-by: Nysal Jan K.A. <nysal@linux.ibm.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Reviewed-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Reviewed-by: Michael Ellerman <mpe@ellerman.id.au>
Reviewed-by: Segher Boessenkool <segher@kernel.crashing.org>
Link: https://lore.kernel.org/r/20250303060457.531293-1-nysal@linux.ibm.com
The last use of paravirt_disable_iospace() was removed in 2015 by
commit d1c29465b8 ("lguest: don't disable iospace.")
Remove it.
Note the comment above it about 'entry.S' is unrelated to this
but stayed when intervening code got deleted.
Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Reviewed-by: Juergen Gross <jgross@suse.com>
Link: https://lore.kernel.org/r/20250303004441.250451-1-linux@treblig.org
It's undesirable to have to figure out the pxp pointer in display
code. For one thing, its type is different for i915 and xe.
Since we can figure the pxp pointer out in the pxp code from the gem
object, offload it there.
v2: Rebase
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Alan Previn <alan.previn.teres.alexis@intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250228114527.3091620-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
pwm-stmpe is the only driver that cannot be built as a module. Add the
necessary boilerplate to also make this driver modular.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Link: https://lore.kernel.org/r/20250215143723.636591-2-u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
Add support for MDB System Level Control and Status Register (SLCR)
aperture that is only supported for AMD Versal2 devices.
Signed-off-by: Thippeswamy Havalige <thippeswamy.havalige@amd.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Acked-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Link: https://lore.kernel.org/r/20250228093351.923615-2-thippeswamy.havalige@amd.com
[kwilczynski: commit log]
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Exynos7870 devices have a DWC3 compatible USB 2.0 controller.
Add support in the driver by:
- Adding its own compatible string, "samsung,exynos7870-dwusb3".
- Adding three USBDRD clocks named "bus_early", "ref", and "ctrl", to
be controlled by the driver.
Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20250301-exynos7870-usb-v3-2-f01697165d19@disroot.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Document compatible string for Exynos7870 DWC3-compatible USB 2.0
driver. The devicetree node requires three clocks, named "bus_early",
"ref", and "ctrl".
Unlike other variants, Exynos7870's USB controller requires a single
3.0V regulator. Assert that the other 1.0V regulator requirement is
enforced on variants individually other than Exynos7870's.
Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20250301-exynos7870-usb-v3-1-f01697165d19@disroot.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The USB dwc3 core on Rockchip's RK3562 is the same as the one already
included in generic snps,dwc3. Extend the binding accordingly to allow
compatible = "rockchip,rk3562-dwc3", "snps,dwc3";
There are 4 clocks with different name sequency, add schema for it.
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://lore.kernel.org/r/20250227111913.2344207-10-kever.yang@rock-chips.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This array is only read, not modified.
Declaring data as const makes it easier to see what's going on, and can
prevent unintended writes through placement in a read-only section.
Signed-off-by: Jonathan Neuschäfer <j.ne@posteo.net>
Reviewed-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/20250228-misc-const-v3-9-09b417ded9c4@posteo.net
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
These arrays are only read, not modified.
Declaring data as const makes it easier to see what's going on, and can
prevent unintended writes through placement in a read-only section.
Signed-off-by: Jonathan Neuschäfer <j.ne@posteo.net>
Reviewed-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/20250228-misc-const-v3-8-09b417ded9c4@posteo.net
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The nand_flash_ids, inquiry_response, and mode_page_01 arrays are only
read, not modified.
Declaring data as const makes it easier to see what's going on, and can
prevent unintended writes through placement in a read-only section.
Signed-off-by: Jonathan Neuschäfer <j.ne@posteo.net>
Reviewed-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/20250228-misc-const-v3-7-09b417ded9c4@posteo.net
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
These arrays are only read, never modified.
Declaring data as const makes it easier to see what's going on, and can
prevent unintended writes through placement in a read-only section.
Signed-off-by: Jonathan Neuschäfer <j.ne@posteo.net>
Reviewed-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/20250228-misc-const-v3-6-09b417ded9c4@posteo.net
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
init_string is only read, not modified.
Declaring data as const makes it easier to see what's going on, and can
prevent unintended writes through placement in a read-only section.
Signed-off-by: Jonathan Neuschäfer <j.ne@posteo.net>
Reviewed-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/20250228-misc-const-v3-5-09b417ded9c4@posteo.net
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
These arrays are only read, not modified.
Declaring data as const makes it easier to see what's going on, and can
prevent unintended writes through placement in a read-only section.
Signed-off-by: Jonathan Neuschäfer <j.ne@posteo.net>
Reviewed-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/20250228-misc-const-v3-4-09b417ded9c4@posteo.net
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The alauda_card_ids array is only read, and not modified.
Declaring data as const makes it easier to see what's going on, and can
prevent unintended writes through placement in a read-only section.
Signed-off-by: Jonathan Neuschäfer <j.ne@posteo.net>
Reviewed-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/20250228-misc-const-v3-3-09b417ded9c4@posteo.net
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This array is only read, not modified.
Declaring data as const makes it easier to see what's going on, and can
prevent unintended writes through placement in a read-only section.
Signed-off-by: Jonathan Neuschäfer <j.ne@posteo.net>
Reviewed-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/20250228-misc-const-v3-2-09b417ded9c4@posteo.net
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
These arrays are not modified. Make them const.
Declaring data as const makes it easier to see what's going on, and can
prevent unintended writes through placement in a read-only section.
Signed-off-by: Jonathan Neuschäfer <j.ne@posteo.net>
Reviewed-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/20250228-misc-const-v3-1-09b417ded9c4@posteo.net
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If no fw_build is recognized for the controller there is no point to
exposing the `do_flash` attribute.
Add an is_visible callback to the attribute group and check for that
fw_build member to hide when not applicable.
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20250221054137.1631765-3-superm1@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The error `failed to get FW build information` is added for what looks
to be for misdetection of the device property firmware-name.
If the property is missing (such as on non-nvidia HW) this error shows up.
Move the error into the scope of the property parser for "firmware-name"
to avoid showing errors on systems without the firmware-name property.
Fixes: 5c9ae5a875 ("usb: typec: ucsi: ccg: add firmware flashing support")
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20250221054137.1631765-2-superm1@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Some platforms like Marvell are cache coherent, so allow the
"dma-coherent" property.
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://lore.kernel.org/r/20250226214231.3745400-1-robh@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
otg_ulpi_create() has been unused since 2022's
commit 8ca79aaad8 ("ARM: pxa: remove unused pxa3xx-ulpi")
Remove it.
The devm_ variant is still used.
Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org>
Link: https://lore.kernel.org/r/20250223160602.91916-1-linux@treblig.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The RichTek RT1711H and RT1719 chips do have a vbus pin that is
used for attach/detach detection (respectively, pin A1 and 11):
allow a vbus-supply phandle for that.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/20250219140143.104037-1-angelogioacchino.delregno@collabora.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The usb_sndaddr0pipe macro is only used in the hub_set_address function.
Replace it with usb_sndctrlpipe which provides the same functionality
but would also consider the endpoint device number.
If the device has not been initialised, it is safe to use
usb_sndctrlpipe in this context because udev->devnum is set to 0.
Therefore, this change does not affect behaviour, but reduces code
complexity by reusing the existing macro.
Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/20250219083745.10406-1-eichest@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The xHC resources allocated for USB devices are not released in correct
order after resuming in case when while suspend device was reconnected.
This issue has been detected during the fallowing scenario:
- connect hub HS to root port
- connect LS/FS device to hub port
- wait for enumeration to finish
- force host to suspend
- reconnect hub attached to root port
- wake host
For this scenario during enumeration of USB LS/FS device the Cadence xHC
reports completion error code for xHC commands because the xHC resources
used for devices has not been properly released.
XHCI specification doesn't mention that device can be reset in any order
so, we should not treat this issue as Cadence xHC controller bug.
Similar as during disconnecting in this case the device resources should
be cleared starting form the last usb device in tree toward the root hub.
To fix this issue usbcore driver should call hcd->driver->reset_device
for all USB devices connected to hub which was reconnected while
suspending.
Fixes: 3d82904559 ("usb: cdnsp: cdns3 Add main part of Cadence USBSSP DRD Driver")
Cc: stable <stable@kernel.org>
Signed-off-by: Pawel Laszczak <pawell@cadence.com>
Reviewed-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/PH7PR07MB953841E38C088678ACDCF6EEDDCC2@PH7PR07MB9538.namprd07.prod.outlook.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Move hdcp_mutex, num_hdcp_streams, hdcp_auth_status, hdcp_port_data, and
hdcp_mst_type1_capable members of struct intel_digital_port under an
hdcp sub-struct to group hdcp related things together.
Rename them mutex, num_streams, auth_status, port_data, and
mst_type1_capable for clarity.
Cc: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/9da4be57b068acd06dec8b93977f0a70627103d4.1740746939.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Move active_mst_links, mst_encoders[], and mst_mgr members of struct
intel_dp under an mst sub-struct to group mst related things together.
Rename them active_links, stream_encoders[] and mgr for clarity.
Note that is_mst and mst_detect are not included, as they're also
relevant for non-mst. The sub-struct is for active mst.
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/6f282f90bfe2dd9162e2dee8f681c84313971992.1740746939.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
When performing continuous unbind/bind operations on the USB drivers
available on the Renesas RZ/G2L SoC, a kernel crash with the message
"Unable to handle kernel NULL pointer dereference at virtual address"
may occur. This issue points to the usbhsc_notify_hotplug() function.
Flush the delayed work to avoid its execution when driver resources are
unavailable.
Fixes: bc57381e63 ("usb: renesas_usbhs: use delayed_work instead of work_struct")
Cc: stable <stable@kernel.org>
Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Tested-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Link: https://lore.kernel.org/r/20250225110248.870417-4-claudiu.beznea.uj@bp.renesas.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The gpriv->transceiver is retrieved in probe() through usb_get_phy() but
never released. Use devm_usb_get_phy() to handle this scenario.
This issue was identified through code investigation. No issue was found
without this change.
Fixes: b5a2875605 ("usb: renesas_usbhs: Allow an OTG PHY driver to provide VBUS")
Cc: stable <stable@kernel.org>
Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Tested-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Link: https://lore.kernel.org/r/20250225110248.870417-3-claudiu.beznea.uj@bp.renesas.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If the USB configuration is not valid, then avoid checking for
bmAttributes to prevent null pointer deference.
Cc: stable <stable@kernel.org>
Fixes: 40e89ff575 ("usb: gadget: Set self-powered based on MaxPower and bmAttributes")
Signed-off-by: Prashanth K <prashanth.k@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250224085604.417327-1-prashanth.k@oss.qualcomm.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When adding support for USB3-over-USB4 tunnelling detection, a check
for an Intel-specific capability was added. This capability, which
goes by ID 206, is used without any check that we are actually
dealing with an Intel host.
As it turns out, the Cadence XHCI controller *also* exposes an
extended capability numbered 206 (for unknown purposes), but of
course doesn't have the Intel-specific registers that the tunnelling
code is trying to access. Fun follows.
The core of the problems is that the tunnelling code blindly uses
vendor-specific capabilities without any check (the Intel-provided
documentation I have at hand indicates that 192-255 are indeed
vendor-specific).
Restrict the detection code to Intel HW for real, preventing any
further explosion on my (non-Intel) HW.
Cc: stable <stable@kernel.org>
Fixes: 948ce83fbb ("xhci: Add USB4 tunnel detection for USB3 devices on Intel hosts")
Signed-off-by: Marc Zyngier <maz@kernel.org>
Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20250227194529.2288718-1-maz@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add support for the Exynos7870 SoC pin-controller in the pinctrl driver.
It has 8 GPIO banks, and 3-bit PINCFG_TYPE_DRV width.
Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
Link: https://lore.kernel.org/r/20250301-exynos7870-pinctrl-v3-3-ba1da9d3cd2f@disroot.org
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
The Embedded Controller in the Huawei Matebook E Go is accessible on &i2c15
and provides battery and adapter status, port orientation status, as well
as HPD event notifications for two USB Type-C port, etc.
Add the EC to the device tree and describe the relationship among
the type-c connectors, role switches, orientation switches and the QMP
combo PHY.
Signed-off-by: Pengyu Luo <mitltlatltl@gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250214180656.28599-4-mitltlatltl@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
