Commit Graph
1399042 Commits
Author SHA1 Message Date
Kuninori Morimoto 130947b468 ASoC: renesas: msiof: set SIFCTR register
Because it uses DMAC, we would like to transfer data if there is any data.
Set SIFCTR for it.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Tested-by: Yusuke Goda <yusuke.goda.sx@renesas.com>
Link: https://patch.msgid.link/87bjmzyuub.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2025-09-25 17:43:25 +01:00
Kuninori Morimoto 25226abc1a ASoC: renesas: msiof: use reset controller
MSIOF has TXRST/RXRST to reset FIFO, but it shouldn't be used during SYNC
signal was asserted, because it will be cause of HW issue.

When MSIOF is used as Sound driver, this driver is assuming it is used as
clock consumer mode (= Codec is clock provider). This means, it can't
control SYNC signal by itself.

We need to use SW reset (= reset_control_xxx()) instead of TXRST/RXRST.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Tested-by: Yusuke Goda <yusuke.goda.sx@renesas.com>
Link: https://patch.msgid.link/87cy7fyuug.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2025-09-25 17:43:24 +01:00
Kuninori Morimoto 030c59df83 ASoC: renesas: msiof: add unique NOTE name
MSIOF will have many NOTE on top of driver, give it a unique NOTE name.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://patch.msgid.link/87ecrvyuuo.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2025-09-25 17:43:23 +01:00
Greg Kroah-Hartman 264a58e60c Merge tag 'usb-serial-6.18-rc1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-next
Johan writes:

USB serial updates for 6.18-rc1

Here are the USB serial updates for 6.18-rc1 consisting of some new
modem device ids and a trivial cleanup.

Everything has been in linux-next with no reported issues.

* tag 'usb-serial-6.18-rc1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial:
  USB: serial: option: add SIMCom 8230C compositions
  USB: serial: oti6858: remove extranenous ; after comment
2025-09-25 18:38:53 +02:00
Greg Kroah-Hartman ef351f8e39 Merge tag 'thunderbolt-for-v6.18-rc1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt into usb-next
Mika writes:

thunderbolt: Changes for v6.18 merge window

This includes following USB4/Thunderbolt changes for the v6.18 merge
window:

  - HMAC hashing improvements
  - Switch to use Linux Foundation IDs for XDomain discovery
  - Use is_pciehp instead of is_hotplug_bridge
  - Fixes for various kernel-doc issues
  - Fix use-after-free in DP tunneling error path.

I'm sending the UAF fix with this pull request because it came quite
late and I would like to give it some exposure before it lands the
mainline.

All these except the UAF fix have been in linux-next with no reported
issues.

* tag 'thunderbolt-for-v6.18-rc1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt: (33 commits)
  thunderbolt: Fix use-after-free in tb_dp_dprx_work
  thunderbolt: Update thunderbolt.h header file
  thunderbolt: Update xdomain.c function documentation
  thunderbolt: Update usb4_port.c function documentation
  thunderbolt: Update usb4.c function documentation
  thunderbolt: Update tunnel.h function documentation
  thunderbolt: Update tunnel.c function documentation
  thunderbolt: Update tmu.c function documentation
  thunderbolt: Add missing documentation in tb.h
  thunderbolt: Update tb.h function documentation
  thunderbolt: Update tb.c function documentation
  thunderbolt: Update switch.c function documentation
  thunderbolt: Update retimer.c function documentation
  thunderbolt: Update property.c function documentation
  thunderbolt: Update path.c function documentation
  thunderbolt: Update nvm.c function documentation
  thunderbolt: Add missing documentation in nhi_regs.h ring_desc structure
  thunderbolt: Update nhi.c function documentation
  thunderbolt: Update lc.c function documentation
  thunderbolt: Update eeprom.c function documentation
  ...
2025-09-25 18:36:54 +02:00
Jaehoon Kim 130e6de621 s390/dasd: enforce dma_alignment to ensure proper buffer validation
The block layer validates buffer alignment using the device's
dma_alignment value. If dma_alignment is smaller than
logical_block_size(bp_block) -1, misaligned buffer incorrectly pass
validation and propagate to the lower-level driver.

This patch adjusts dma_alignment to be at least logical_block_size -1,
ensuring that misalignment buffers are properly rejected at the block
layer and do not reach the DASD driver unnecessarily.

Fixes: 2a07bb64d8 ("s390/dasd: Remove DMA alignment")
Reviewed-by: Stefan Haberland <sth@linux.ibm.com>
Cc: stable@vger.kernel.org #6.11+
Signed-off-by: Jaehoon Kim <jhkim@linux.ibm.com>
Signed-off-by: Stefan Haberland <sth@linux.ibm.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2025-09-25 10:34:30 -06:00
Jaehoon Kim 8f4ed0ce48 s390/dasd: Return BLK_STS_INVAL for EINVAL from do_dasd_request
Currently, if CCW request creation fails with -EINVAL, the DASD driver
returns BLK_STS_IOERR to the block layer.

This can happen, for example, when a user-space application such as QEMU
passes a misaligned buffer, but the original cause of the error is
masked as a generic I/O error.

This patch changes the behavior so that -EINVAL is returned as
BLK_STS_INVAL, allowing user space to properly detect alignment issues
instead of interpreting them as I/O errors.

Reviewed-by: Stefan Haberland <sth@linux.ibm.com>
Cc: stable@vger.kernel.org #6.11+
Signed-off-by: Jaehoon Kim <jhkim@linux.ibm.com>
Signed-off-by: Stefan Haberland <sth@linux.ibm.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2025-09-25 10:34:30 -06:00
Linus Torvalds 4ff71af020 Merge tag 'net-6.17-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net
Pull networking fixes from Paolo Abeni:
 "Including fixes from Bluetooth, IPsec and CAN.

  No known regressions at this point.

  Current release - regressions:

   - xfrm: xfrm_alloc_spi shouldn't use 0 as SPI

  Previous releases - regressions:

   - xfrm: fix offloading of cross-family tunnels

   - bluetooth: fix several races leading to UaFs

   - dsa: lantiq_gswip: fix FDB entries creation for the CPU port

   - eth:
       - tun: update napi->skb after XDP process
       - mlx: fix UAF in flow counter release

  Previous releases - always broken:

   - core: forbid FDB status change while nexthop is in a group

   - smc: fix warning in smc_rx_splice() when calling get_page()

   - can: provide missing ndo_change_mtu(), to prevent buffer overflow.

   - eth:
       - i40e: fix VF config validation
       - broadcom: fix support for PTP_EXTTS_REQUEST2 ioctl"

* tag 'net-6.17-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (40 commits)
  octeontx2-pf: Fix potential use after free in otx2_tc_add_flow()
  net: dsa: lantiq_gswip: suppress -EINVAL errors for bridge FDB entries added to the CPU port
  net: dsa: lantiq_gswip: move gswip_add_single_port_br() call to port_setup()
  libie: fix string names for AQ error codes
  net/mlx5e: Fix missing FEC RS stats for RS_544_514_INTERLEAVED_QUAD
  net/mlx5: HWS, ignore flow level for multi-dest table
  net/mlx5: fs, fix UAF in flow counter release
  selftests: fib_nexthops: Add test cases for FDB status change
  selftests: fib_nexthops: Fix creation of non-FDB nexthops
  nexthop: Forbid FDB status change while nexthop is in a group
  net: allow alloc_skb_with_frags() to use MAX_SKB_FRAGS
  bnxt_en: correct offset handling for IPv6 destination address
  ptp: document behavior of PTP_STRICT_FLAGS
  broadcom: fix support for PTP_EXTTS_REQUEST2 ioctl
  broadcom: fix support for PTP_PEROUT_DUTY_CYCLE
  Bluetooth: MGMT: Fix possible UAFs
  Bluetooth: hci_event: Fix UAF in hci_acl_create_conn_sync
  Bluetooth: hci_event: Fix UAF in hci_conn_tx_dequeue
  Bluetooth: hci_sync: Fix hci_resume_advertising_sync
  Bluetooth: Fix build after header cleanup
  ...
2025-09-25 08:23:52 -07:00
Vadim Pasternak 1e11552ee5 hwmon: (mlxreg-fan) Add support for new flavour of capability register
FAN platform data is common across the various systems, while fan
driver should be able to apply only the fan instances relevant
to specific system.

For example, platform data might contain descriptions for fan1,
fan2, ..., fan{n}, while some systems equipped with all 'n' fans,
others with less.
Also, on some systems fan drawer can be equipped with several
tachometers and on others only with one.

For detection of the real number of equipped drawers and tachometers
special capability registers are used.
These registers used to indicate presence of drawers and tachometers
through the bitmap.

For some new big modular systems this register will provide presence
data by counter.

Use slot parameter to distinct whether capability register contains
bitmask or counter.

Signed-off-by: Vadim Pasternak <vadimp@nvidia.com>
Link: https://lore.kernel.org/r/20250113084859.27064-3-vadimp@nvidia.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-09-25 08:08:14 -07:00
Vadim Pasternak c02e4644f8 hwmon: (mlxreg-fan) Separate methods of fan setting coming from different subsystems
Distinct between fan speed setting request coming for hwmon and
thermal subsystems.

There are fields 'last_hwmon_state' and 'last_thermal_state' in the
structure 'mlxreg_fan_pwm', which respectively store the cooling state
set by the 'hwmon' and 'thermal' subsystem.
The purpose is to make arbitration of fan speed setting. For example, if
fan speed required to be not lower than some limit, such setting is to
be performed through 'hwmon' subsystem, thus 'thermal' subsystem will
not set fan below this limit.

Currently, the 'last_thermal_state' is also be updated by 'hwmon' causing
cooling state to never be set to a lower value.

Eliminate update of 'last_thermal_state', when request is coming from
'hwmon' subsystem.

Fixes: da74944d3a ("hwmon: (mlxreg-fan) Use pwm attribute for setting fan speed low limit")
Signed-off-by: Vadim Pasternak <vadimp@nvidia.com>
Link: https://lore.kernel.org/r/20250113084859.27064-2-vadimp@nvidia.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-09-25 08:08:14 -07:00
Sung-Chi Li 5798b62867 hwmon: (cros_ec) register fans into thermal framework cooling devices
Register fans connected under EC as thermal cooling devices as well, so
these fans can then work with the thermal framework.

During the driver probing phase, we will also try to register each fan
as a thermal cooling device based on previous probe result (whether the
there are fans connected on that channel, and whether EC supports fan
control). The basic get max state, get current state, and set current
state methods are then implemented as well.

Signed-off-by: Sung-Chi Li <lschyi@chromium.org>
Acked-by: Thomas Weißschuh <linux@weissschuh.net>
Link: https://lore.kernel.org/r/20250911-cros_ec_fan-v6-3-a1446cc098af@google.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-09-25 08:08:14 -07:00
Sung-Chi Li fb8e659309 hwmon: (cros_ec) add PWM control over fans
Newer EC firmware supports controlling fans through host commands, so
adding corresponding implementations for controlling these fans in the
driver for other kernel services and userspace to control them.

The driver will first probe the supported host command versions (get and
set of fan PWM values, get and set of fan control mode) to see if the
connected EC fulfills the requirements of controlling the fan, then
exposes corresponding sysfs nodes for userspace to control the fan with
corresponding read and write implementations.
As EC will automatically change the fan mode to auto when the device is
suspended, the power management hooks are added as well to keep the fan
control mode and fan PWM value consistent during suspend and resume. As
we need to access the hwmon device in the power management hook, update
the driver by storing the hwmon device in the driver data as well.

Signed-off-by: Sung-Chi Li <lschyi@chromium.org>
Acked-by: Thomas Weißschuh <linux@weissschuh.net>
Link: https://lore.kernel.org/r/20250911-cros_ec_fan-v6-2-a1446cc098af@google.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-09-25 08:08:13 -07:00
Sung-Chi Li 60ac65a310 platform/chrome: update pwm fan control host commands
Update cros_ec_commands.h to include definitions for getting PWM fan
duty, getting and setting the fan control mode.

Signed-off-by: Sung-Chi Li <lschyi@chromium.org>
Acked-by: Tzung-Bi Shih <tzungbi@kernel.org>
Reviewed-by: Thomas Weißschuh <linux@weissschuh.net>
Link: https://lore.kernel.org/r/20250911-cros_ec_fan-v6-1-a1446cc098af@google.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-09-25 08:08:13 -07:00
Michael Walle 443b39c82c hwmon: add SMARC-sAM67 support
Add a new driver for the Kontron SMARC-sAM67 board management
controller. It has two voltage sensors and one temperature sensor.

Signed-off-by: Michael Walle <mwalle@kernel.org>
Link: https://lore.kernel.org/r/20250912120745.2295115-7-mwalle@kernel.org
[groeck: Added sa67 to index.rst]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-09-25 08:08:13 -07:00
Michael Walle 0f6eae86e6 dt-bindings: hwmon: sl28cpld: add sa67mcu compatible
The Kontron SMARC-sAM67 module features an on-board house keeping uC.
It is designed to be compatible with the older sl28cpld implementation,
but has different sensors, like voltage and temperature monitoring. Add
a new compatible for that board.

Signed-off-by: Michael Walle <mwalle@kernel.org>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20250912120745.2295115-5-mwalle@kernel.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-09-25 08:08:13 -07:00
Mohamad Kamal 31c092baea hwmon: (asus-ec-sensors) add TUF GAMING X670E PLUS WIFI
Add support for TUF GAMING X670E PLUS WIFI

Signed-off-by: Mohamad Kamal <mohamad.kamal.85@gmail.com>
Signed-off-by: Eugene Shalygin <eugene.shalygin@gmail.com>
Link: https://lore.kernel.org/r/20250914084019.1108941-1-eugene.shalygin@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-09-25 08:08:13 -07:00
Linus Torvalds 93a2744561 Merge tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost
Pull virtio fixes from Michael Tsirkin:
 "virtio,vhost: last minute fixes

  More small fixes. Most notably this fixes crashes and hangs in
  vhost-net"

* tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost:
  MAINTAINERS, mailmap: Update address for Peter Hilber
  virtio_config: clarify output parameters
  uapi: vduse: fix typo in comment
  vhost: Take a reference on the task in struct vhost_task.
  vhost-net: flush batched before enabling notifications
  Revert "vhost/net: Defer TX queue re-enable until after sendmsg"
  vhost-net: unbreak busy polling
  vhost-scsi: fix argument order in tport allocation error message
2025-09-25 08:06:03 -07:00
Darrick J. Wong cb40359470 fuse: move CREATE_TRACE_POINTS to a separate file
Before we start adding new tracepoints for fuse+iomap, move the
tracepoint creation itself to a separate source file so that we don't
have to start pulling iomap dependencies into dev.c just for the iomap
structures.

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
2025-09-25 16:22:18 +02:00
Darrick J. Wong c4331e19a6 fuse: move the backing file idr and code into a new source file
iomap support for fuse is also going to want the ability to attach
backing files to a fuse filesystem.  Move the fuse_backing code into a
separate file so that both can use it.

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
2025-09-25 16:06:02 +02:00
Sergey Bashirov db155b7c7c NFSD: Disallow layoutget during grace period
When the server is recovering from a reboot and is in a grace period,
any operation that may result in deletion or reallocation of block
extents should not be allowed. See RFC 8881, section 18.43.3.

If multiple clients write data to the same file, rebooting the server
during writing may result in file corruption. In the worst case, the
exported XFS may also become corrupted. Observed this behavior while
testing pNFS block volume setup.

Co-developed-by: Konstantin Evtushenko <koevtushenko@yandex.com>
Signed-off-by: Konstantin Evtushenko <koevtushenko@yandex.com>
Signed-off-by: Sergey Bashirov <sergeybashirov@gmail.com>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2025-09-25 10:01:24 -04:00
John Hubbard 6d97171ac6 rust: pci: display symbolic PCI vendor names
The Display implementation for Vendor was forwarding directly to Debug
printing, resulting in raw hex values instead of PCI Vendor strings.

Improve things by doing a stringify!() call for each PCI Vendor item.
This now prints symbolic names such as "NVIDIA", instead of
"Vendor(0x10de)". It still falls back to Debug formatting for unknown
class values.

Suggested-by: Danilo Krummrich <dakr@kernel.org>
Signed-off-by: John Hubbard <jhubbard@nvidia.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
[ Remove #[inline] for Vendor::fmt(). - Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-09-25 15:52:00 +02:00
Marek Vasut 0a8f173d9d PCI: rcar-host: Drop PMSR spinlock
The pmsr_lock spinlock used to be necessary to synchronize access to the
PMSR register, because that access could have been triggered from either
config space access in rcar_pcie_config_access() or an exception handler
rcar_pcie_aarch32_abort_handler().

The rcar_pcie_aarch32_abort_handler() case is no longer applicable since
commit 6e36203bc1 ("PCI: rcar: Use PCI_SET_ERROR_RESPONSE after read
which triggered an exception"), which performs more accurate, controlled
invocation of the exception, and a fixup.

This leaves rcar_pcie_config_access() as the only call site from which
rcar_pcie_wakeup() is called. The rcar_pcie_config_access() can only be
called from the controller struct pci_ops .read and .write callbacks,
and those are serialized in drivers/pci/access.c using raw spinlock
'pci_lock' . It should be noted that CONFIG_PCI_LOCKLESS_CONFIG is never
set on this platform.

Since the 'pci_lock' is a raw spinlock , and the 'pmsr_lock' is not a
raw spinlock, this constellation triggers 'BUG: Invalid wait context'
with CONFIG_PROVE_RAW_LOCK_NESTING=y .

Remove the pmsr_lock to fix the locking.

Fixes: a115b1bd3a ("PCI: rcar: Add L1 link state fix into data abort hook")
Reported-by: Duy Nguyen <duy.nguyen.rh@renesas.com>
Reported-by: Thuan Nguyen <thuan.nguyen-hong@banvien.com.vn>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20250909162707.13927-1-marek.vasut+renesas@mailbox.org
2025-09-25 19:21:17 +05:30
John Hubbard d53ea977ad rust: pci: display symbolic PCI class names
The Display implementation for Class was forwarding directly to Debug
printing, resulting in raw hex values instead of PCI Class strings.

Improve things by doing a stringify!() call for each PCI Class item.
This now prints symbolic names such as "DISPLAY_VGA", instead of
"Class(0x030000)". It still falls back to Debug formatting for unknown
class values.

Suggested-by: Danilo Krummrich <dakr@kernel.org>
Signed-off-by: John Hubbard <jhubbard@nvidia.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-09-25 15:51:16 +02:00
Kevin Brodsky 200b0d2508 arm64: mm: Move KPTI helpers to mmu.c
create_kpti_ng_temp_pgd() is currently defined (as an alias) in
mmu.c without matching declaration in a header; instead cpufeature.c
makes its own declaration. This is clearly not pretty, and as commit
ceca927c86 ("arm64: mm: Fix CFI failure due to kpti_ng_pgd_alloc
function signature") showed, it also makes it very easy for the
prototypes to go out of sync.

All this would be much simpler if kpti_install_ng_mappings() and
associated functions lived in mmu.c, where they logically belong.
This is what this patch does:
- Move kpti_install_ng_mappings() and associated functions from
  cpufeature.c to mmu.c, add a declaration to <asm/mmu.h>
- Remove create_kpti_ng_temp_pgd() and just call
  __create_pgd_mapping_locked() directly instead
- Mark all these functions __init
- Move __initdata after kpti_ng_temp_alloc (as suggested by
  checkpatch)

Reviewed-by: Ryan Roberts <ryan.roberts@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
Signed-off-by: Kevin Brodsky <kevin.brodsky@arm.com>
Reviewed-by: Yeoreum Yun <yeoreum.yun@arm.com>
[will: Fix conflicts with init_idmap_kpti_bbml2_flag()]
Signed-off-by: Will Deacon <will@kernel.org>
2025-09-25 14:47:19 +01:00
Krishna Chaitanya Chundru 0da48c5b2f PCI: dwc: Support ECAM mechanism by enabling iATU 'CFG Shift Feature'
Designware databook r5.20a, sec 3.10.10.3 documents the 'CFG Shift Feature'
of the internal Address Translation Unit (iATU). When this feature is
enabled, it shifts/maps the BDF contained in the bits [27:12] of the target
address in MEM TLP to become BDF of the CFG TLP. This essentially
implements the Enhanced Configuration Address Mapping (ECAM) mechanism as
defined in PCIe r6.0, sec 7.2.2.

Currently, the driver is not making use of this CFG shift feature, thereby
creating the iATU outbound map for each config access to the devices,
causing latency and wasting CPU cycles.

So to avoid this, configure the controller to enable CFG shift feature by
enabling the 'CFG Shift' bit of the 'iATU Control 2 Register'.

As a result of enabling CFG shift (ECAM), there is no longer a need to map
the DBI register space separately as the DBI region falls under the
'config' space used for ECAM (as DBI is used to access the Root Port).

For enabling ECAM using CFG shift, the platform has to satisfy following
requirements:

  1. Size of the 'config' memory space to be used as ECAM memory should be
     able to accommodate the number of buses defined in the 'bus-range'
     property of the host bridge DT node.

  2. The 'config' memory space should be 256 MiB aligned. This requirement
     comes from PCIe r6.0, sec 7.2.2, which says the base address of ECAM
     memory should be aligned to a 2^(n+20) byte address boundary. For the
     DWC cores, n is 8, so this results in 2^28 byte alignment requirement.

It should be noted that some DWC vendor glue drivers like pcie-al may use
their own ECAM mechanism. For those controllers, set
'dw_pcie_rp::native_ecam' flag and skip enabling the CFG Shift feature in
the DWC core.

Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
[mani: code split, reworded subject/description, comment, native_ecam flag]
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Link: https://patch.msgid.link/20250923-controller-dwc-ecam-v10-4-e84390ba75fa@kernel.org
2025-09-25 18:34:01 +05:30
Krishna Chaitanya Chundru 4660e50cf8 PCI: qcom: Prepare for the DWC ECAM enablement
To support the DWC ECAM mechanism, prepare the driver by performing below
configurations:

  1. Since the ELBI region will be covered by the ECAM 'config' space,
     override the 'elbi_base' with the address derived from 'dbi_base' and
     the offset from PARF_SLV_DBI_ELBI register.

  2. Block the transactions from the host bridge to devices other than Root
     Port on the root bus to return all F's. This is required when the 'CFG
     Shift Feature' of iATU is enabled.

Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
[mani: code split, reworded subject/description and comments]
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Link: https://patch.msgid.link/20250923-controller-dwc-ecam-v10-3-e84390ba75fa@kernel.org
2025-09-25 18:33:56 +05:30
Krishna Chaitanya Chundru f6fd357f7a PCI: dwc: Prepare the driver for enabling ECAM mechanism using iATU 'CFG Shift Feature'
In order to enable PCIe ECAM mechanism in DWC driver as per the 'CFG Shift
Feature' documented in Designware databook r5.20a, sec 3.10.10.3, prepare
the driver to handle the one time iATU setup and creating ECAM window.

Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
[mani: splitted the preparatory code into a separate commit for bisectability]
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Link: https://patch.msgid.link/20250923-controller-dwc-ecam-v10-2-e84390ba75fa@kernel.org
2025-09-25 18:33:52 +05:30
Krishna Chaitanya Chundru c96992a24b PCI: dwc: Add support for ELBI resource mapping
External Local Bus Interface (ELBI) is an optional register space for all
DWC IPs containing the vendor specific registers. There is no need for the
vendor glue drivers to fetch and map the ELBI region separately.

Hence, optionally fetch and map the resource from DT in the DWC core. This
also warrants dropping the corresponding code from glue drivers. Hence,
drop the ELBI resource fetch and map logic from glue drivers and convert
them to use 'dw_pci::elbi_base'.

Note that the pcie-qcom-ep driver used devm_pci_remap_cfg_resource() to map
the ELBI resource previously. But it was a mistake since
devm_pci_remap_cfg_resource() should only be used for mapping the PCIe
config space region as it maps the region as Non-Posted. As ELBI is used to
hold vendor specific registers, there is no need to map the region as
Non-Posted. With this conversion, the region will get mapped as normal MMIO
memory.

Suggested-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
[mani: removed elbi override, converted glue drivers and reworded description]
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Link: https://patch.msgid.link/20250923-controller-dwc-ecam-v10-1-e84390ba75fa@kernel.org
2025-09-25 18:33:37 +05:30
Feng Yang fd2f74f8f3 tracing: Fix the bug where bpf_get_stackid returns -EFAULT on the ARM64
When using bpf_program__attach_kprobe_multi_opts on ARM64 to hook a BPF program
that contains the bpf_get_stackid function, the BPF program fails
to obtain the stack trace and returns -EFAULT.

This is because ftrace_partial_regs omits the configuration of the pstate register,
leaving pstate at the default value of 0. When get_perf_callchain executes,
it uses user_mode(regs) to determine whether it is in kernel mode.
This leads to a misjudgment that the code is in user mode,
so perf_callchain_kernel is not executed and the function returns directly.
As a result, trace->nr becomes 0, and finally -EFAULT is returned.

Therefore, the assignment of the pstate register is added here.

Fixes: b9b55c8912 ("tracing: Add ftrace_partial_regs() for converting ftrace_regs to pt_regs")
Closes: https://lore.kernel.org/bpf/20250919071902.554223-1-yangfeng59949@163.com/
Signed-off-by: Feng Yang <yangfeng@kylinos.cn>
Tested-by: Jiri Olsa <jolsa@kernel.org>
Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Signed-off-by: Will Deacon <will@kernel.org>
2025-09-25 13:59:26 +01:00
Yang Shi 195a1b7d83 arm64: kprobes: call set_memory_rox() for kprobe page
The kprobe page is allocated by execmem allocator with ROX permission.
It needs to call set_memory_rox() to set proper permission for the
direct map too. It was missed.

Fixes: 10d5e97c1b ("arm64: use PAGE_KERNEL_ROX directly in alloc_insn_page")
Cc: <stable@vger.kernel.org>
Signed-off-by: Yang Shi <yang@os.amperecomputing.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Will Deacon <will@kernel.org>
2025-09-25 13:56:48 +01:00
Greg Kroah-Hartman c584a1c7c8 USB: disable rust bindings from the build for now
The rust USB bindings as submitted are a good start, but they don't
really seem to be correct in a number of minor places, so just disable
them from the build entirely at this point in time.  When they are ready
to be re-enabled, this commit can be reverted.

Acked-by: Daniel Almeida <daniel.almeida@collabora.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-09-25 14:53:47 +02:00
Yicong Yang a084c3c4a2 drivers/perf: hisi: Add tt_core_deprecated for compatibility
Previously tt_core is defined as config1:0-7 which may not cover all
the CPUs sharing L3C on platforms with more than 8 CPUs in a L3C. In
order to support such platforms extend tt_core to 16 bits, since no
spare space in config1, tt_core was moved to config2:0-15.

Though linux expects the users to retrieve the control encoding from
sysfs first for each option, it's possible if user doesn't follow
this and hardcoded tt_core in config1. So add an option
tt_core_deprecated for config1:0-7 for backward compatibility.

Signed-off-by: Yicong Yang <yangyicong@hisilicon.com>
Signed-off-by: Will Deacon <will@kernel.org>
2025-09-25 13:51:59 +01:00
Heiko Carstens 088bb10e37 s390/mm: Add memory allocation profiling hooks
Similar to common code changes [1] add alloc_hook() wrappers to page table
allocation functions to allow for memory allocation profiling.

If CONFIG_MEM_ALLOC_PROFILING is enabled call sites of page table
allocations are accounted, instead of e.g. only crst_table_alloc() and
page_table_alloc(). This allows for slightly better profiling data, and the
output of /proc/allocinfo is similar to other architectures.

Without alloc_hook() wrappers the output of /proc/allocinfo looks like
this:

    17096704     4174 mm/memory.c:1061 func:folio_prealloc
    17809408     4348 mm/memory.c:1063 func:folio_prealloc
           0        0 mm/memory.c:4422 func:alloc_swap_folio
           0        0 mm/memory.c:4286 func:__alloc_swap_folio
           0        0 mm/memory.c:4971 func:alloc_anon_folio
         ...
     1589248       97 arch/s390/mm/pgalloc.c:25 func:crst_table_alloc
           0        0 arch/s390/mm/pgalloc.c:124 func:page_table_alloc_pgste
     4280320     1045 arch/s390/mm/pgalloc.c:149 func:page_table_alloc

With alloc_hook() wrappers:

     1097728      268 mm/memory.c:5147 func:__do_fault
    20119552     4912 mm/memory.c:1061 func:folio_prealloc
    17534976     4281 mm/memory.c:1063 func:folio_prealloc
           0        0 mm/memory.c:4422 func:alloc_swap_folio
           0        0 mm/memory.c:4286 func:__alloc_swap_folio
      786432      192 mm/memory.c:452 func:__pte_alloc
      405504       99 mm/memory.c:464 func:__pte_alloc_kernel
     1880064      459 mm/memory.c:5525 func:do_fault_around
           0        0 mm/memory.c:6403 func:__p4d_alloc
           0        0 mm/memory.c:6426 func:__pud_alloc
     1064960       65 mm/memory.c:6450 func:__pmd_alloc
           0        0 mm/memory.c:4971 func:alloc_anon_folio
           0        0 mm/memory.c:5233 func:do_set_pmd

[1] commit 2c321f3f70 ("mm: change inlined allocation helpers to account at the call site")

Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Acked-by: Alexander Gordeev <agordeev@linux.ibm.com>
Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2025-09-25 14:28:58 +02:00
Marco Crivellari 72105fc1c1 s390: Replace use of system_wq with system_dfl_wq
Currently if a user enqueue a work item using schedule_delayed_work() the
used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use
WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to
schedule_work() that is using system_wq and queue_work(), that makes use
again of WORK_CPU_UNBOUND.

This lack of consistentcy cannot be addressed without refactoring the API.

system_wq is a per-CPU worqueue (replaced by system_percpu_wq), but the
current code does not benefit from it. Because of that, system_wq has been
replaced by system_dfl_wq, the new unbound workqueue.

The old wq will be kept for a few release cylces.

Suggested-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
Acked-by: Heiko Carstens <hca@linux.ibm.com>
Reviewed-by: Mete Durlu <meted@linux.ibm.com>
Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2025-09-25 14:28:58 +02:00
Marco Crivellari dbfe205a34 s390/diag324: Replace use of system_wq with system_percpu_wq
Currently if a user enqueue a work item using schedule_delayed_work() the
used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use
WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to
schedule_work() that is using system_wq and queue_work(), that makes use
again of WORK_CPU_UNBOUND.

This lack of consistentcy cannot be addressed without refactoring the API.

system_wq is a per-CPU worqueue, yet nothing in its name tells about that
CPU affinity constraint, which is very often not required by users. Make
it clear by renaming system_wq to system_percpu_wq.

queue_work() / queue_delayed_work() mod_delayed_work() will now use the
new per-cpu wq.

The old wq will be kept for a few release cylces.

Suggested-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
Acked-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2025-09-25 14:28:58 +02:00
Marco Crivellari f707d2f7a0 s390/tape: Add WQ_PERCPU to alloc_workqueue users
Currently if a user enqueue a work item using schedule_delayed_work() the
used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use
WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to
schedule_work() that is using system_wq and queue_work(), that makes use
again of WORK_CPU_UNBOUND.
This lack of consistentcy cannot be addressed without refactoring the API.

alloc_workqueue() treats all queues as per-CPU by default, while unbound
workqueues must opt-in via WQ_UNBOUND.

This default is suboptimal: most workloads benefit from unbound queues,
allowing the scheduler to place worker threads where they’re needed and
reducing noise when CPUs are isolated.

This patch adds a new WQ_PERCPU flag to explicitly request the use of
the per-CPU behavior. Both flags coexist for one release cycle to allow
callers to transition their calls.

Once migration is complete, WQ_UNBOUND can be removed and unbound will
become the implicit default.

With the introduction of the WQ_PERCPU flag (equivalent to !WQ_UNBOUND),
any alloc_workqueue() caller that doesn’t explicitly specify WQ_UNBOUND
must now use WQ_PERCPU.

All existing users have been updated accordingly.

Suggested-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
Acked-by: Alexander Gordeev <agordeev@linux.ibm.com>
Acked-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2025-09-25 14:28:58 +02:00
Harrison Carter 64826db1e2 dt-bindings: leds: as3645: Convert to DT schema
Convert the ams,as3645a.txt to DT Schema format.

Signed-off-by: Harrison Carter <hcarter@thegoodpenguin.co.uk>
Reviewed-by: "Rob Herring (Arm)" <robh@kernel.org>
Signed-off-by: Lee Jones <lee@kernel.org>
2025-09-25 13:01:32 +01:00
Lukas Bulwahn 017bdcdb3a MAINTAINERS: Adjust file entry in LOONGSON SECURITY ENGINE DRIVERS
Commit 5c83b07df9 ("tpm: Add a driver for Loongson TPM device") adds a
driver at drivers/char/tpm/tpm_loongson.c, and commit 74fddd5fba
("MAINTAINERS: Add entry for Loongson Security Engine drivers") adds a new
section LOONGSON SECURITY ENGINE DRIVERS intending to refer to that driver.
It however adds the entry drivers/char/tpm_loongson.c; note that it misses
the tpm subdirectory.

Adjust the entry to refer to the intended file.

Fixes: 74fddd5fba ("MAINTAINERS: Add entry for Loongson Security Engine drivers")
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@redhat.com>
Signed-off-by: Lee Jones <lee@kernel.org>
2025-09-25 12:59:30 +01:00
Nathan Chancellor a727bc0588 tpm: loongson: Add bufsiz parameter to tpm_loongson_send()
Commit 5c83b07df9 ("tpm: Add a driver for Loongson TPM device") has a
semantic conflict with commit 07d8004d6f ("tpm: add bufsiz parameter
in the .send callback"), as the former change was developed against a
tree without the latter change. This results in a build error:

  drivers/char/tpm/tpm_loongson.c:48:17: error: initialization of 'int (*)(struct tpm_chip *, u8 *, size_t,  size_t)' {aka 'int (*)(struct tpm_chip *, unsigned char *, long unsigned int,  long unsigned int)'} from incompatible pointer type 'int (*)(struct tpm_chip *, u8 *, size_t)' {aka 'int (*)(struct tpm_chip *, unsigned char *, long unsigned int)'} [-Wincompatible-pointer-types]
     48 |         .send = tpm_loongson_send,
        |                 ^~~~~~~~~~~~~~~~~
  drivers/char/tpm/tpm_loongson.c:48:17: note: (near initialization for 'tpm_loongson_ops.send')
  drivers/char/tpm/tpm_loongson.c:31:12: note: 'tpm_loongson_send' declared here
     31 | static int tpm_loongson_send(struct tpm_chip *chip, u8 *buf, size_t count)
        |            ^~~~~~~~~~~~~~~~~

Add the expected bufsiz parameter to tpm_loongson_send() to resolve the
error.

Fixes: 5c83b07df9 ("tpm: Add a driver for Loongson TPM device")
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Lee Jones <lee@kernel.org>
2025-09-25 12:45:03 +01:00
Masahiro Yamada 37fac070eb Documentation: kbuild: note CONFIG_DEBUG_EFI in reproducible builds
CONFIG_EFI_DEBUG embeds absolute file paths into object files, which
makes the resulting vmlinux specific to the build environment.

Add a note about this in reproducible-builds.rst

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Nicolas Schier <nsc@kernel.org>
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Link: https://patch.msgid.link/20250924-kbuild-doc-config-debug-efi-in-reproducible-builds-v2-1-d2d6b9dcdb7d@kernel.org
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
2025-09-25 04:41:48 -07:00
Magnus Karlsson dd948aa63e MAINTAINERS: Delete inactive maintainers from AF_XDP
Delete Björn Töpel and Jonathan Lemon as maintainer and reviewer,
respectively, as they have not been contributing towards AF_XDP for
several years. I have spoken to Björn and he is ok with his removal.

Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: Jason Xing <kerneljasonxing@gmail.com>
Acked-by: Björn Töpel <bjorn@kernel.org>
Link: https://lore.kernel.org/bpf/20250915120148.2922-1-magnus.karlsson@gmail.com
2025-09-25 13:18:22 +02:00
Paolo Abeni 12de5f0f6c Merge branch 'net-gso-restore-outer-ip-ids-correctly'
Richard Gobert says:

====================
net: gso: restore outer ip ids correctly

GRO currently ignores outer IPv4 header IDs for encapsulated packets
that have their don't-fragment flag set. GSO, however, always assumes
that outer IP IDs are incrementing. This results in GSO mangling the
outer IDs when they aren't incrementing. For example, GSO mangles the
outer IDs of IPv6 packets that were converted to IPv4, which must
have an ID of 0 according to RFC 6145, sect. 5.1.

GRO+GSO is supposed to be entirely transparent by default. GSO already
correctly restores inner IDs and IDs of non-encapsulated packets. The
tx-tcp-mangleid-segmentation feature can be enabled to allow the
mangling of such IDs so that TSO can be used.

This series fixes outer ID restoration for encapsulated packets when
tx-tcp-mangleid-segmentation is disabled. It also allows GRO to merge
packets with fixed IDs that don't have their don't-fragment flag set.

v1: https://lore.kernel.org/netdev/20250814114030.7683-1-richardbgobert@gmail.com/
v2: https://lore.kernel.org/netdev/20250819063223.5239-1-richardbgobert@gmail.com/
v3: https://lore.kernel.org/netdev/20250821073047.2091-1-richardbgobert@gmail.com/
v4: https://lore.kernel.org/netdev/20250901113826.6508-1-richardbgobert@gmail.com/
v5: https://lore.kernel.org/netdev/20250915113933.3293-1-richardbgobert@gmail.com/
v6: https://lore.kernel.org/netdev/20250916144841.4884-1-richardbgobert@gmail.com/
v7: https://lore.kernel.org/netdev/20250922084103.4764-1-richardbgobert@gmail.com/
====================

Link: https://patch.msgid.link/20250923085908.4687-1-richardbgobert@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-25 12:42:52 +02:00
Richard Gobert 5e9ff9378a selftests/net: test ipip packets in gro.sh
Add IPIP test-cases to the GRO selftest.

This selftest already contains IP ID test-cases. They are now
also tested for encapsulated packets.

This commit also fixes ipip packet generation in the test.

Signed-off-by: Richard Gobert <richardbgobert@gmail.com>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Link: https://patch.msgid.link/20250923085908.4687-6-richardbgobert@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-25 12:42:49 +02:00
Richard Gobert f095a358fa net: gro: remove unnecessary df checks
Currently, packets with fixed IDs will be merged only if their
don't-fragment bit is set. This restriction is unnecessary since
packets without the don't-fragment bit will be forwarded as-is even
if they were merged together. The merged packets will be segmented
into their original forms before being forwarded, either by GSO or
by TSO. The IDs will also remain identical unless NETIF_F_TSO_MANGLEID
is set, in which case the IDs can become incrementing, which is also fine.

Clean up the code by removing the unnecessary don't-fragment checks.

Signed-off-by: Richard Gobert <richardbgobert@gmail.com>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Link: https://patch.msgid.link/20250923085908.4687-5-richardbgobert@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-25 12:42:49 +02:00
Richard Gobert 3271f19bf7 net: gso: restore ids of outer ip headers correctly
Currently, NETIF_F_TSO_MANGLEID indicates that the inner-most ID can
be mangled. Outer IDs can always be mangled.

Make GSO preserve outer IDs by default, with NETIF_F_TSO_MANGLEID allowing
both inner and outer IDs to be mangled.

This commit also modifies a few drivers that use SKB_GSO_FIXEDID directly.

Signed-off-by: Richard Gobert <richardbgobert@gmail.com>
Reviewed-by: Edward Cree <ecree.xilinx@gmail.com> # for sfc
Reviewed-by: Willem de Bruijn <willemb@google.com>
Link: https://patch.msgid.link/20250923085908.4687-4-richardbgobert@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-25 12:42:49 +02:00
Richard Gobert 21f7484220 net: gro: only merge packets with incrementing or fixed outer ids
Only merge encapsulated packets if their outer IDs are either
incrementing or fixed, just like for inner IDs and IDs of non-encapsulated
packets.

Add another ip_fixedid bit for a total of two bits: one for outer IDs (and
for unencapsulated packets) and one for inner IDs.

This commit preserves the current behavior of GSO where only the IDs of the
inner-most headers are restored correctly.

Signed-off-by: Richard Gobert <richardbgobert@gmail.com>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Link: https://patch.msgid.link/20250923085908.4687-3-richardbgobert@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-25 12:42:49 +02:00
Richard Gobert 25c550464a net: gro: remove is_ipv6 from napi_gro_cb
Remove is_ipv6 from napi_gro_cb and use sk->sk_family instead.
This frees up space for another ip_fixedid bit that will be added
in the next commit.

udp_sock_create always creates either a AF_INET or a AF_INET6 socket,
so using sk->sk_family is reliable. In IPv6-FOU, cfg->ipv6_v6only is
always enabled.

Signed-off-by: Richard Gobert <richardbgobert@gmail.com>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Link: https://patch.msgid.link/20250923085908.4687-2-richardbgobert@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-25 12:42:49 +02:00
Mohsin Bashir bb6a22651b eth: fbnic: Read module EEPROM
Add support to read module EEPROM for fbnic. Towards this, add required
support to issue a new command to the firmware and to receive the response
to the corresponding command.

Create a local copy of the data in the completion struct before writing to
ethtool_module_eeprom to avoid writing to data in case it is freed. Given
that EEPROM pages are small, the overhead of additional copy is
negligible.

Do not block API with explicit checks since API has appropriate checks in
place for length, offset, and page.

Explicitly check bank, page, offset, and length in
fbnic_fw_parse_qsfp_read_resp() to match EEPROM read responses to the
correct request. This is important because if the driver times out waiting
for an EEPROM read response, a subsequent read request with different
values is susceptible to receiving an erroneous response (i.e., the
response to the previous request).

Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Mohsin Bashir <mohsin.bashr@gmail.com>
Link: https://patch.msgid.link/20250922231855.3717483-1-mohsin.bashr@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-25 11:58:49 +02:00
Daniel Lee 3ed17349f1 platform/x86: lg-laptop: Fix WMAB call in fan_mode_store()
When WMAB is called to set the fan mode, the new mode is read from either
bits 0-1 or bits 4-5 (depending on the value of some other EC register).
Thus when WMAB is called with bits 4-5 zeroed and called again with
bits 0-1 zeroed, the second call undoes the effect of the first call.
This causes writes to /sys/devices/platform/lg-laptop/fan_mode to have
no effect (and causes reads to always report a status of zero).

Fix this by calling WMAB once, with the mode set in bits 0,1 and 4,5.
When the fan mode is returned from WMAB it always has this form, so
there is no need to preserve the other bits.  As a bonus, the driver
now supports the "Performance" fan mode seen in the LG-provided Windows
control app, which provides less aggressive CPU throttling but louder
fan noise and shorter battery life.

Also, correct the documentation to reflect that 0 corresponds to the
default mode (what the Windows app calls "Optimal") and 1 corresponds
to the silent mode.

Fixes: dbf0c5a6b1 ("platform/x86: Add LG Gram laptop special features driver")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=204913#c4
Signed-off-by: Daniel Lee <dany97@live.ca>
Link: https://patch.msgid.link/MN2PR06MB55989CB10E91C8DA00EE868DDC1CA@MN2PR06MB5598.namprd06.prod.outlook.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-09-25 12:21:43 +03:00
Dan Carpenter d9c70e93ec octeontx2-pf: Fix potential use after free in otx2_tc_add_flow()
This code calls kfree_rcu(new_node, rcu) and then dereferences "new_node"
and then dereferences it on the next line.  Two lines later, we take
a mutex so I don't think this is an RCU safe region.  Re-order it to do
the dereferences before queuing up the free.

Fixes: 68fbff68db ("octeontx2-pf: Add police action for TC flower")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>
Link: https://patch.msgid.link/aNKCL1jKwK8GRJHh@stanley.mountain
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-25 11:04:34 +02:00