| Age | Commit message (Collapse) | Author |
|---|
|
The driver was disabling the USB2 PHY clock immediately after register
initialization in probe() and after each reset operation. This left the
PHY unclocked even though it must remain active for USB functionality.
The behavior appeared to work only when another driver
(e.g., USB controller) had already enabled the clock, making operation
unreliable and hardware-dependent. In configurations where this driver
is the sole clock user, USB functionality would fail.
Fix this by:
- Enabling the clock once in probe() via pm_runtime_resume_and_get()
- Removing all pm_runtime_put() calls from assert/deassert/status
- Registering a devm cleanup action to release the clock at removal
- Removed rzv2h_usbphy_assert_helper() and its call in
rzv2h_usb2phy_reset_probe()
This ensures the PHY clock remains enabled for the entire device lifetime,
preventing instability and aligning with hardware requirements.
Cc: stable@vger.kernel.org
Fixes: e3911d7f865b ("reset: Add USB2PHY port reset driver for Renesas RZ/V2H(P)")
Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
|
|
Create an additional auxiliary device to support fwctl.
The next patch will create bnxt_fwctl and bind to this
device.
Link: https://patch.msgid.link/r/20260314151605.932749-4-pavan.chebbi@broadcom.com
Reviewed-by: Andy Gospodarek <gospo@broadcom.com>
Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: Pavan Chebbi <pavan.chebbi@broadcom.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
|
|
Up until now there was only one auxiliary device that bnxt
created and that was for RoCE driver. bnxt fwctl is also
going to use an aux bus device that bnxt should create.
This requires some nomenclature changes and refactoring of
the existing bnxt aux dev functions.
Convert 'aux_priv' and 'edev' members of struct bnxt into
arrays where each element contains supported auxbus device's
data. Move struct bnxt_aux_priv from bnxt.h to ulp.h because
that is where it belongs. Make aux bus init/uninit/add/del
functions more generic which will loop through all the aux
device types. Make bnxt_ulp_start/stop functions (the only
other common functions applicable to any aux device) loop
through the aux devices to update their config and states.
Make callers of bnxt_ulp_start() call it only when there
are no errors.
Also, as an improvement in code, bnxt_register_dev() can skip
unnecessary dereferencing of edev from bp, instead use the
edev pointer from the function parameter.
Future patches will reuse these functions to add an aux bus
device for fwctl.
Link: https://patch.msgid.link/r/20260314151605.932749-3-pavan.chebbi@broadcom.com
Reviewed-by: Andy Gospodarek <gospo@broadcom.com>
Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: Pavan Chebbi <pavan.chebbi@broadcom.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
|
|
We have common definitions that are now going to be used
by more than one component outside of bnxt (bnxt_re and
fwctl)
Move bnxt_ulp.h to include/linux/bnxt/ as ulp.h.
Link: https://patch.msgid.link/r/20260314151605.932749-2-pavan.chebbi@broadcom.com
Reviewed-by: Andy Gospodarek <gospo@broadcom.com>
Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
Cc: linux-rdma@vger.kernel.org
Signed-off-by: Pavan Chebbi <pavan.chebbi@broadcom.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
|
|
Convert confirm_rx to little endian when enqueueing and convert it back on
receive. This fixes control flow on big endian hosts, little endian is
unaffected.
On transmit, store confirm_rx as __le32 using cpu_to_le32(). On receive,
apply le32_to_cpu() before using the value. !! ensures the value is 0 or 1
in native endianness, so the conversion isn’t strictly required here, but
it is kept for consistency and clarity.
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Alexander Wilhelm <alexander.wilhelm@westermo.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
emac_dispatch_skb_zc() allocates a new skb via napi_alloc_skb() but
never copies the packet data from the XDP buffer into it. The skb is
passed up the stack containing uninitialized heap memory instead of
the actual received packet, leaking kernel heap contents to userspace.
Copy the received packet data from the XDP buffer into the skb using
skb_copy_to_linear_data().
Additionally, remove the skb_mark_for_recycle() call since the skb is
backed by the NAPI page frag allocator, not page_pool. Marking a
non-page_pool skb for recycle causes the free path to return pages to
a page_pool that does not own them, corrupting page_pool state.
The non-ZC path (emac_rx_packet) does not have these issues because it
uses napi_build_skb() to wrap the existing page_pool page directly,
requiring no copy, and correctly marks for recycle since the page comes
from page_pool_dev_alloc_pages().
Fixes: 7a64bb388df3 ("net: ti: icssg-prueth: Add AF_XDP zero copy for RX")
Signed-off-by: David Carlier <devnexen@gmail.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
When driver signals carrier up via netif_carrier_on() its internal
link_up state isn't updated immediately. This leads to inconsistent
speed/duplex in /proc/net/bonding/bondX where the speed and duplex
is shown as unknown while ethtool shows correct values. Fix this by
using netif_carrier_ok() for link checking in get_ksettings function.
Fixes: 84421b99cedc ("tg3: Update link_up flag for phylib devices")
Signed-off-by: Thomas Bogendoerfer <tbogendoerfer@suse.de>
Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
ioam6_fill_trace_data() stores the schema contribution to the trace
length in a u8. With bit 22 enabled and the largest schema payload,
sclen becomes 1 + 1020 / 4, wraps from 256 to 0, and bypasses the
remaining-space check. __ioam6_fill_trace_data() then positions the
write cursor without reserving the schema area but still copies the
4-byte schema header and the full schema payload, overrunning the trace
buffer.
Keep sclen in an unsigned int so the remaining-space check and the write
cursor calculation both see the full schema length.
Fixes: 8c6f6fa67726 ("ipv6: ioam: IOAM Generic Netlink API")
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Reviewed-by: Justin Iurman <justin.iurman@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into soc/dt
Armv8 Juno/FVP/Vexpress updates for v7.1
1. The primary addition is initial support for Zena CSS that includes:
a new binding compatibility, a shared `zena-css.dtsi` description, and
an FVP device tree.
2. Extension of Corstone-1000 FVP platform support with binding updates
to add the new `arm,corstone1000-a320-fvp` platform, and the
`arm,corstone1000-ethos-u85` NPU integration.
Overall, this combines new platform enablement with some DTS layout
cleanup for Arm reference FVP based systems.
* tag 'juno-updates-7.1' of https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux:
arm64: dts: arm/corstone1000: Add corstone-1000-a320
arm64: dts: arm/corstone1000: Move FVP peripherals to separate .dtsi
arm64: dts: arm/corstone1000: Move cpu nodes
dt-bindings: npu: arm,ethos: Add "arm,corstone1000-ethos-u85"
dt-bindings: arm,corstone1000: Add "arm,corstone1000-a320-fvp"
arm64: dts: zena: Move SRAM into SoC and memory node out of SoC
arm64: dts: zena: Add support for Zena CSS
dt-bindings: arm: Add Zena CSS compatibility
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
|
|
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into arm/fixes
Revert to fix a regression that breaks Wifi support for a large part
of Pinebook Pro users (multiple Wifi chipsets).
* tag 'v7.0-rockchip-dtsfixes1-v2' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip:
Revert "arm64: dts: rockchip: Further describe the WiFi for the Pinebook Pro"
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/frank.li/linux into arm/fixes
i.MX fixes for 7.0:
- Revert the NAND property move that broke compatibility across multiple
imx6/imx7 device trees
- Fix imx8mq-librem5 power management by bumping BUCK1 suspend voltage to
0.85V and reverting problematic DVS voltage changes
- Correct eMMC pad configuration for imx93-tqma9352 and imx91-tqma9131
- Change usdhc tuning step for eMMC and SD on imx93-9x9-qsb
- Correct gpu_ahb clock frequency for imx8mq
* tag 'imx-fixes-7.0' of https://git.kernel.org/pub/scm/linux/kernel/git/frank.li/linux:
arm64: dts: imx8mq-librem5: Bump BUCK1 suspend voltage up to 0.85V
Revert "arm64: dts: imx8mq-librem5: Set the DVS voltages lower"
Revert "ARM: dts: imx: move nand related property under nand@0"
arm64: dts: imx93-tqma9352: improve eMMC pad configuration
arm64: dts: imx91-tqma9131: improve eMMC pad configuration
arm64: dts: imx93-9x9-qsb: change usdhc tuning step for eMMC and SD
arm64: dts: imx8mq: Set the correct gpu_ahb clock frequency
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
|
|
There was a recent request [1] to mark as `#[inline]` the simple
`From::from()` functions implemented for `Error`.
Thus mark all of the existing
impl From<...> for Error {
fn from(err: ...) -> Self {
...
}
}
functions in the `kernel` crate as `#[inline]`.
Suggested-by: Gary Guo <gary@garyguo.net>
Link: https://lore.kernel.org/all/8403c8b7a832b5274743816eb77abfa4@garyguo.net/ [1]
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Acked-by: Danilo Krummrich <dakr@kernel.org>
Acked-by: Andreas Hindborg <a.hindborg@kernel.org>
Link: https://patch.msgid.link/20260326020406.1438210-1-alistair.francis@wdc.com
[ Dropped `projection.rs` since it is in another tree and already marked
as `inline(always)` and reworded accordingly. Changed Link tag to
Gary's original message and added Suggested-by. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
|
|
Commit 7d6899fb69d25 ("ovl: fsync after metadata copy-up") was done to
fix durability of overlayfs copy up on an upper filesystem which does
not enforce ordering on storing of metadata changes (e.g. ubifs).
In an earlier revision of the regressing commit by Lei Lv, the metadata
fsync behavior was opt-in via a new "fsync=strict" mount option.
We were hoping that the opt-in mount option could be avoided, so the
change was only made to depend on metacopy=off, in the hope of not
hurting performance of metadata heavy workloads, which are more likely
to be using metacopy=on.
This hope was proven wrong by a performance regression report from Google
COS workload after upgrade to kernel 6.12.
This is an adaptation of Lei's original "fsync=strict" mount option
to the existing upstream code.
The new mount option is mutually exclusive with the "volatile" mount
option, so the latter is now an alias to the "fsync=volatile" mount
option.
Reported-by: Chenglong Tang <chenglongtang@google.com>
Closes: https://lore.kernel.org/linux-unionfs/CAOdxtTadAFH01Vui1FvWfcmQ8jH1O45owTzUcpYbNvBxnLeM7Q@mail.gmail.com/
Link: https://lore.kernel.org/linux-unionfs/CAOQ4uxgKC1SgjMWre=fUb00v8rxtd6sQi-S+dxR8oDzAuiGu8g@mail.gmail.com/
Fixes: 7d6899fb69d25 ("ovl: fsync after metadata copy-up")
Depends: 50e638beb67e0 ("ovl: Use str_on_off() helper in ovl_show_options()")
Cc: stable@vger.kernel.org # v6.12+
Signed-off-by: Fei Lv <feilv@asrmicro.com>
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
|
|
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/mediatek/linux into soc/dt
MediaTek ARM32 Device Tree Updates
This adds a single commit fixing a dtbs_check validation error
by changing the fallback compatible of the efuse node to the
correct one in MT7623.
* tag 'mtk-dts32-for-v7.1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/mediatek/linux:
ARM: dts: mediatek: mt7623: fix efuse fallback compatible
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
|
|
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/mediatek/linux into soc/dt
MediaTek ARM64 DeviceTree updates
This adds fixes and improvements for already supported devices.
In particular:
- The gpio-ranges pin could was fixed in MT6795, MT7981B, and
MT7986A SoCs, as the very last GPIO was unusable; Even though
anyway unused, this fixes the hardware description.
- Model string fixes for Bananapi BPI-R4 Pro 4E/8X: now the
correct model is shown.
- The MT6359 PMIC gets disambiguation for two default regulator
names, mainly fixing issues seen on U-Boot, but also making
the regulators visually distinguishable in a summary...!
- Aliases for eMMC/SD controllers added in MT8365 EVK board,
MT8395 Radxa NIO-12L and Genio 1200 for consistency
- Fixes to the MediaTek AUDSYS devicetree binding
....and honorable mention goes to:
- MT8195 Cherry Chromebooks get their WiFi on PCI Express and
Bluetooth on USB described with the proper power supplies now
tied to the correct devices (USB VBUS and PCIE3v3): this is
now described almost perfectly, or at least links the right
resources in the right places.
This is also done as a preparation for when the M.2 E-Key
connector binding will be upstreamed.
- MT8195 Cherry Dojo gets its M.2 M-Key slot correctly described
with the new pcie-m2-m-connector binding.
* tag 'mtk-dts64-for-v7.1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/mediatek/linux:
arm64: dts: mediatek: mt7986a: Fix gpio-ranges pin count
arm64: dts: mediatek: mt7981b: Fix gpio-ranges pin count
arm64: dts: mediatek: mt6795: Fix gpio-ranges pin count
dt-bindings: arm: mediatek: audsys: fix formatting issues
arm64: dts: mediatek: mt8195-cherry-dojo: Describe M.2 M-key NVMe slot
arm64: dts: mediatek: mt8195-cherry: add WiFi PCIe and BT USB power supplies
arm64: dts: mediatek: mt7988a-bpi-r4pro: fix model string
arm64: dts: mt8167: Reorder nodes according to mmio address
arm64: dts: mediatek: mt6359: give regulators unique names
arm64: dts: mediatek: mt8365: Describe infracfg-nao as a pure syscon
arm64: dts: mediatek: mt8365-evk: add mmc aliases
arm64: dts: mediatek: mt8395-radxa-nio-12l: add mmc aliases
arm64: dts: mediatek: mt8395-genio-common: add mmc aliases
arm64: dts: mediatek: mt8195-cherry: Disable xhci1 completely
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/fustini/linux into soc/dt
T-HEAD Devicetrees for 7.1
Update the T-Head TH1520 RISC-V SoC device tree to support the
Verisilicon DC8200 display controller (called DPU in manual) and the
Synopsys DesignWare HDMI TX controller. In addition, enable HDMI output
for the LicheePi 4a board.
* tag 'thead-dt-for-v7.1' of https://git.kernel.org/pub/scm/linux/kernel/git/fustini/linux:
riscv: dts: thead: lichee-pi-4a: enable HDMI
riscv: dts: thead: add DPU and HDMI device tree nodes
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
|
|
We have three copies of the "read vblank counter and timestamp
in a loop" code. Consolidate to a single a function.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260323213645.10965-1-ville.syrjala@linux.intel.com
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
|
|
This platform is a similar vintage of platforms that had a BIOS bug
leading to a 10s delay at resume from s0i3.
Add a quirk for it.
Reported-by: Imrane <ihalim.me@gmail.com>
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221273
Tested-by: Imrane <ihalim.me@gmail.com>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://patch.msgid.link/20260324211647.357924-1-mario.limonciello@amd.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
The current implementation doesn't require any changes to support minor
version 3, hence increment it to avoid "Unsupported minor version:3"
message.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Link: https://patch.msgid.link/20260325193158.3417382-2-srinivas.pandruvada@linux.intel.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
The current implementation doesn't require any changes to support minor
version 3, hence increment it to avoid "Unsupported minor version:3"
message.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Link: https://patch.msgid.link/20260325193158.3417382-1-srinivas.pandruvada@linux.intel.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
Due to Rust macro scoping rules, all macros defined in a crate using
`#[macro_export]` end up in the top-level. For the list macros, we
re-export them inside the list module, and expect users to use
`kernel::list::macro_name!()`.
Use `#[doc(hidden)]` on the macro definition, and use `#[doc(inline)]` on
the re-export to make the macro appear to be defined at module-level inside
documentation.
The other exported types are already automatically `#[doc(inline)]` because
they are defined in a non-public module, so there is no need to split the
macro re-exports out.
Signed-off-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260312174700.4016015-1-gary@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
|
|
`.rustfmt.toml` is not covered by `MAINTAINERS`, so tools like
`scripts/get_maintainer.pl` do not report it properly, e.g.:
$ scripts/get_maintainer.pl -f .rustfmt.toml
linux-kernel@vger.kernel.org (open list)
It should have been there since the beginning, and while it is not a big
deal since the file has not changed at all since it was added in commit
80db40bac8f4 ("rust: add `.rustfmt.toml`") back in 2022, this will be
especially useful to catch unintended unstable features if upstream
`rustfmt` started to allow them in stable toolchains [1][2].
Thus add it.
Link: https://github.com/rust-lang/rustfmt/issues/6829#issuecomment-4084325200 [1]
Link: https://github.com/rust-lang/rustfmt/issues/4884 [2]
Fixes: 80db40bac8f4 ("rust: add `.rustfmt.toml`")
Link: https://patch.msgid.link/20260323024206.129401-1-ojeda@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
|
|
When the AUTONOMOUS_UFS_DISABLED bit is set in the header, the ELC
(Efficiency Latency Control) feature is non-functional. Hence, return
error for read or write to ELC attributes.
Fixes: bb516dc79c4a ("platform/x86/intel-uncore-freq: Add support for efficiency latency control")
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260325192909.3417322-1-srinivas.pandruvada@linux.intel.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
We're mixing up the GT FIFO debug checks (overflows and such)
with RMbus unclaimed register checks. The two are quite different
things as RMbus is only relevant for display registers, and the
GT FIFO only relevant for GT registers.
Split the GT FIFO debugs out from the unclaimed register logic
and just do the checks during forcewake_get() and early init.
That is still sufficient to detect if any errors have happened.
Any errors would anyway be caused by overflowing the FIFO
rather than accessing specific registers, so trying to figure
out exactly when the error happened isn't particularly useful.
To fix such issues we'd rather have to do something to slow down
the rate at which registers are accessed (eg. increase
GT_FIFO_NUM_RESERVED_ENTRIES or something).
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260323101609.8391-3-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
|
The live_forcewake_domains selftest doesn't really test anything
particularly sensible. It only runs on platforms that have RMbus
unclaimer error detection, but that only catches display registers
which the test doesn't even access.
I suppose if we really wanted to we might try to make the test
exercise the GT FIFO instead by writing GT registers as fast
as possible, and then checking GTFIFODBG to see if the FIFO has
overflowed. But dunno if there's much point in that. I think a
GT FIFO overflow might even be fatal to the machine.
So in its current for the test doesn't really make sense,
and it's in the way of moving all the RMbus noclaim stuff
to the display driver side. So let's just get rid of it.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260323101609.8391-2-ville.syrjala@linux.intel.com
Acked-by: Jani Nikula <jani.nikula@intel.com>
|
|
This simplifies error handling and protects against memory leaks.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
In preparation to making use of __free(...) cleanup facilities to
clean up temporary buffers, factor out code parsing collections into
a separate function to make the code simpler.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
TGL/ADL DSI can be configured to place the clock lane into
LP state during LPM, if otherwise configured for continuous
HS clock.
Hook that up. VBT tells us whether this should be done.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260326111814.9800-6-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
|
TGL/ADL DSI can be configured to fill all BLLPs with blanking
packets. Currently we enable that always, but the VBT actually
tells us whether this is desired or not. Hook that up.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260326111814.9800-5-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
|
Based on feature revision, number of buckets can be less than the
TRL_MAX_BUCKETS. In that case core counts in the remaining buckets
can be set to some invalid values.
Hence reset core count to 0 for all buckets before assigning correct
values.
Fixes: 885d1c2a30b7 ("platform/x86: ISST: Support SST-TF revision 2")
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260325192638.3417281-1-srinivas.pandruvada@linux.intel.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
Since the PM core automatically falls back to using the driver PM
callbacks directly if no bus type callbacks are present, it is not
necessary to define a struct dev_pm_ops for a bus type that will only
invoke driver PM callbacks from its PM callbacks.
Accordingly, auxiliary_dev_pm_ops is redundant, so drop it.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://patch.msgid.link/4738700.LvFx2qVVIh@rafael.j.wysocki
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The DSI 'clock_stop' parameter is a boolean, so use a real
'bool' for it. And pimp the debug print while at it.
Note that we also remove the incorrect negation of the value
in the debug print. That has been there since the code was
introduced in commit 2ab8b458c6a1 ("drm/i915: Add support for
Generic MIPI panel driver"). An earlier version of the patch
https://lore.kernel.org/intel-gfx/1397454507-10273-5-git-send-email-shobhit.kumar@intel.com/
got it right, but looks like it got fumbled while dealing
with other review comments.
v2: Highlight the removal of the '!' (Jani)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260326111814.9800-4-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
|
|
|
|
|
eotp == "End of Transmission Packet". Drop the redundant
extra 'p' from 'eotp_pkt', and make the thing a boolean
while at it.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260326111814.9800-3-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
|
Stop adjusting the horizontal timing values based on the
compression ratio in command mode. Bspec seems to be telling
us to do this only in video mode, and this is also how the
Windows driver does things.
This should also fix a div-by-zero on some machines because
the adjusted htotal ends up being so small that we end up with
line_time_us==0 when trying to determine the vtotal value in
command mode.
Note that this doesn't actually make the display on the
Huawei Matebook E work, but at least the kernel no longer
explodes when the driver loads.
Cc: stable@vger.kernel.org
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/12045
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260326111814.9800-2-ville.syrjala@linux.intel.com
Fixes: 53693f02d80e ("drm/i915/dsi: account for DSC in horizontal timings")
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
|
The newly added hid-lenovo-go and hid-lenovo-go-s drivers attempt to
'select LEDS_CLASS', which has a dependency on NEW_LEDS, causing a build
failure when NEW_LEDS itself it disabled:
WARNING: unmet direct dependencies detected for LEDS_CLASS
Depends on [n]: NEW_LEDS [=n]
Selected by [m]:
- HID_LENOVO_GO [=m] && HID_SUPPORT [=y] && HID [=m] && USB_HID [=m]
- HID_LENOVO_GO_S [=m] && HID_SUPPORT [=y] && HID [=m] && USB_HID [=m]
WARNING: unmet direct dependencies detected for LEDS_CLASS_MULTICOLOR
Depends on [n]: NEW_LEDS [=n] && LEDS_CLASS [=m]
Selected by [m]:
- HID_LENOVO_GO [=m] && HID_SUPPORT [=y] && HID [=m] && USB_HID [=m]
- HID_LENOVO_GO_S [=m] && HID_SUPPORT [=y] && HID [=m] && USB_HID [=m]
ERROR: modpost: "led_set_brightness_nopm" [drivers/leds/led-class.ko] undefined!
ERROR: modpost: "led_set_brightness" [drivers/leds/led-class.ko] undefined!
ERROR: modpost: "led_get_color_name" [drivers/leds/led-class-multicolor.ko] undefined!
ERROR: modpost: "led_set_brightness" [drivers/leds/led-class-multicolor.ko] undefined!
Device drivers generally should not select other subsystems like this, as
that tends to cause dependency problems including loops in the dependency
graph.
Change these two and the older hid-lenovo driver to behave the same way as all
other HID drivers and use 'depends on LEDS_CLASS' or 'depends on LEDS_CLASS_MULTICOLOR'
instead, which itself has NEW_LEDS and LEDS_CLASS as dependencies.
Fixes: a23f3497bf20 ("HID: hid-lenovo-go-s: Add Lenovo Legion Go S Series HID Driver")
Fixes: d69ccfcbc955 ("HID: hid-lenovo-go: Add Lenovo Legion Go Series HID Driver")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
According to a mailing list report [1], this controller's predecessor
has the same issue. However, it uses the xpad driver instead of HID, so
this quirk wouldn't apply.
[1]: https://lore.kernel.org/linux-input/unufo3$det$1@ciao.gmane.io/
Signed-off-by: leo vriska <leo@60228.dev>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
roccat_report_event() iterates over the device->readers list without
holding the readers_lock. This allows a concurrent roccat_release() to
remove and free a reader while it's still being accessed, leading to a
use-after-free.
Protect the readers list traversal with the readers_lock mutex.
Signed-off-by: Benoît Sevens <bsevens@google.com>
Reviewed-by: Silvan Jegen <s.jegen@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
tidss encoder-bridge is not added with drm_bridge_add() call, which
leads to:
[drm] Missing drm_bridge_add() before attach
Add the missing call, using devm_drm_bridge_add() variant to get the
drm_bridge_remove() handled automatically.
The commit marked with the Fixes tag (from v6.6) is the commit that
added the encoder bridge without drm_bridge_add(). However, this fix is
not directly applicable there as devm_drm_bridge_alloc() was not used to
alloc the bridge, so using devm version for drm_bridge_add() wouldn't be
safe. Instead, drm_bridge_add() and drm_bridge_remove() would be needed
there, but that would require new plumbing code as we don't have a
separate cleanup function in the tidss_encoder.c, not in the tidss_kms.c
from which the encoder is created.
Also, there has been no reported bugs caused by the missing
drm_bridge_add(). The drm_bridge_add() initializes the bridge's
hpd_mutex, but HPD is not used for the encoder bridge. drm_bridge_add()
also adds the bridge to the global bridge_list, which is only used in
of_drm_find_bridge(), and again that is not used for the encoder bridge.
Thus, while the original commit is not right, there should be no bugs
caused by it, and for the time being I'm not sending a patch for the
stable kernels for the original commit.
This fix applies on top of commit 66cdf05f8548 ("drm/tidss: encoder:
convert to devm_drm_bridge_alloc()"), which changes the tidss_encoder.c
to use the devm variant (added in v6.17). The warning print was added in
v6.19, so applying this fix to v6.17+ gets rid of the warning for all
kernel versions.
Cc: stable@vger.kernel.org # v6.17+
Fixes: c932ced6b585 ("drm/tidss: Update encoder/bridge chain connect model")
Acked-by: Maxime Ripard <mripard@kernel.org>
Link: https://patch.msgid.link/20260311-tidss-minor-fixes-v2-2-cb4479784458@ideasonboard.com
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
|
|
We are calling drm_mode_config_reset() twice at probe time. There's no
reason for this and the second call can be removed, reducing work at
probe time slightly.
Fixes: 32a1795f57ee ("drm/tidss: New driver for TI Keystone platform Display SubSystem")
Acked-by: Maxime Ripard <mripard@kernel.org>
Link: https://patch.msgid.link/20260311-tidss-minor-fixes-v2-1-cb4479784458@ideasonboard.com
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
|
|
of_property_read_u32 returns 0 on success. The current check returns
-EINVAL if the property is read successfully.
Fix the check by removing ! from of_property_read_u32
Fixes: b9c7aff481f1 ("drivers/thermal/spear_thermal.c: add Device Tree probing capability")
Signed-off-by: Gopi Krishna Menon <krishnagopi487@gmail.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano@kernel.org>
Suggested-by: Daniel Baluta <daniel.baluta@nxp.com>
Reviewed-by: Lukasz Luba <lukasz.luba@arm.com>
Link: https://patch.msgid.link/20260327090526.59330-1-krishnagopi487@gmail.com
|
|
Document the compatible for Qualcomm Eliza SoC TSENS module, fully
compatible with TSENS v2 generation (e.g. SM8650).
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260327100733.365573-2-krzysztof.kozlowski@oss.qualcomm.com
Signed-off-by: Daniel Lezcano <daniel.lezcano@kernel.org>
|
|
As part of an effort to refactor user_mem_abort() into smaller, more
focused helper functions, extract the logic responsible for determining
the VMA shift and page size into a new static helper,
kvm_s2_resolve_vma_size().
Reviewed-by: Joey Gouly <joey.gouly@arm.com>
Signed-off-by: Fuad Tabba <tabba@google.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
|
|
Commit d6edc31f3a68 ("clk: qcom: smd-rpm: Separate out interconnect bus
clocks") moved control over several RPM resources from the clk-smd-rpm
driver to the icc-rpm.c interconnect helpers. Most of the platforms were
fixed before that commit or shortly after. However the MSM8974 was left
as a foster child in broken state. Fix the loose ends and reenable
interconnects on that platform.
* icc-msm8974
dt-bindings: interconnect: qcom,msm8974: drop bus clocks
dt-bindings: interconnect: qcom,msm8974: use qcom,rpm-common
interconnect: qcom: drop unused is_on flag
interconnect: qcom: icc-rpm: allow overwriting get_bw callback
interconnect: qcom: define OCMEM bus resource
interconnect: qcom: let platforms declare their bugginess
interconnect: qcom: msm8974: switch to the main icc-rpm driver
interconnect: qcom: msm8974: expand DEFINE_QNODE macros
Link: https://msgid.link/20260324-msm8974-icc-v2-0-527280043ad8@oss.qualcomm.com
Tested-by: Alexandre Messier <alex@me.ssier.org>
Tested-by: Luca Weiss <luca.weiss@fairphone.com> # fairphone-fp2
Signed-off-by: Georgi Djakov <djakov@kernel.org>
|
|
Correct the upper bound from CTIINOUTEN_MAX to config->nr_trig_max,
since nr_trig_max varies across CTI devices. An out-of-bounds issue
occurs when a value greater than config->nr_trig_max is provided,
leading to unexpected errors.
Fixes: b5213376c240 ("coresight: cti: Add sysfs access to program function registers")
Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
Reviewed-by: Leo Yan <leo.yan@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Link: https://lore.kernel.org/r/20260327-fix-cti-issue-v1-1-2c8921e21fc8@oss.qualcomm.com
|
|
The behavior of RTLA on receiving SIGINT is currently undocumented.
Describe it in RTLA's common appendix that appears in man pages for all
RTLA tools to avoid confusion.
Suggested-by: Attila Fazekas <afazekas@redhat.com>
Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Link: https://lore.kernel.org/r/20260324123229.152424-1-tglozar@redhat.com
Signed-off-by: Tomas Glozar <tglozar@redhat.com>
|
|
commit 30b3211aa2416 ("ALSA: hda/intel: Add MSI X870E Tomahawk
to denylist") was added to silence a warning, but this effectively
reintroduced commit df42ee7e22f03 ("ALSA: hda: Add ASRock
X670E Taichi to denylist") which was already reported to cause
problems and reverted in commit ee8f1613596ad ("Revert "ALSA: hda:
Add ASRock X670E Taichi to denylist"")
Revert it yet again.
Cc: stable@vger.kernel.org
Reported-by: Juhyun Song <juju6985@outlook.kr>
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221274
Cc: Stuart Hayhurst <stuart.a.hayhurst@gmail.com>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://patch.msgid.link/20260326190542.524515-1-mario.limonciello@amd.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Replace memset() followed by memcpy() with memcpy_and_pad() to simplify
the code and to write to ->auth_key only once.
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
Add the missing > characters to the end of the email address
Signed-off-by: Mieczyslaw Nalewaj <namiltd@yahoo.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
