]> git.ipfire.org Git - thirdparty/kernel/linux.git/log
thirdparty/kernel/linux.git
4 months agoMerge tag 'samsung-soc-6.15' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk...
Arnd Bergmann [Wed, 19 Mar 2025 21:39:11 +0000 (22:39 +0100)] 
Merge tag 'samsung-soc-6.15' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux into soc/drivers

Samsung mach/soc changes for v6.15

1. S3C: Drop linux/fb.h header.
2. Exynos ChipID: Check if memory allocation succeeded.

* tag 'samsung-soc-6.15' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux:
  soc: samsung: exynos-chipid: Add NULL pointer check in exynos_chipid_probe()
  ARM: s3c: Do not include <linux/fb.h>

Link: https://lore.kernel.org/r/20250309185601.10616-3-krzysztof.kozlowski@linaro.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
4 months agoMerge tag 'samsung-drivers-6.15' of https://git.kernel.org/pub/scm/linux/kernel/git...
Arnd Bergmann [Wed, 19 Mar 2025 21:37:38 +0000 (22:37 +0100)] 
Merge tag 'samsung-drivers-6.15' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux into soc/drivers

Samsung SoC drivers for v6.15

1. Add support for Exynos USI v1 serial engines.  Drivers already
   supported newer IP blocks - USI v2 - present in Exynos850 and newer.
   A bit older ARM64 designs, like Exynos8895 use older USI v1 block.

2. Add Exynos ACPM (Alive Clock and Power Manager) protocol driver
   for Google GS101 SoC.  ACPM protocol allows communication between the
   power management firmware and other embedded processors.

3. Exynos2200: Add PMU, ChipID and SYSREG Devicetree bindings.

4. Exynos7870: Add PMU and ChipID Devicetree bindings.

5. Various cleanups.

* tag 'samsung-drivers-6.15' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux:
  dt-bindings: soc: samsung: exynos-usi: Drop unnecessary status from example
  soc: samsung: include linux/array_size.h where needed
  soc: samsung: exynos-chipid: add support for exynos7870
  dt-bindings: soc: samsung: exynos-pmu: add exynos7870-pmu compatible
  dt-bindings: hwinfo: samsung,exynos-chipid: add exynos7870-chipid compatible
  soc: samsung: exynos-chipid: add exynos2200 SoC support
  dt-bindings: hwinfo: samsung,exynos-chipid: add exynos2200 compatible
  dt-bindings: soc: samsung: exynos-pmu: add exynos2200 compatible
  dt-bindings: soc: samsung: exynos-sysreg: add sysreg compatibles for exynos2200
  firmware: Exynos ACPM: Fix spelling mistake "Faile" -> "Failed"
  MAINTAINERS: add entry for the Samsung Exynos ACPM mailbox protocol
  firmware: add Exynos ACPM protocol driver
  dt-bindings: firmware: add google,gs101-acpm-ipc
  soc: samsung: usi: implement support for USIv1 and exynos8895
  soc: samsung: usi: add a routine for unconfiguring the ip
  dt-bindings: soc: samsung: usi: add USIv1 and samsung,exynos8895-usi
  soc: samsung: Use syscon_regmap_lookup_by_phandle_args

Link: https://lore.kernel.org/r/20250309185601.10616-1-krzysztof.kozlowski@linaro.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
4 months agoMerge tag 'tegra-for-6.15-firmware' of https://git.kernel.org/pub/scm/linux/kernel...
Arnd Bergmann [Wed, 19 Mar 2025 21:37:00 +0000 (22:37 +0100)] 
Merge tag 'tegra-for-6.15-firmware' of https://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into soc/drivers

firmware: tegra: Changes for v6.15-rc1

Not much to this except for a simple typofix.

* tag 'tegra-for-6.15-firmware' of https://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux:
  firmware: tegra: bpmp: Fix typo in bpmp-abi.h

Link: https://lore.kernel.org/r/20250307162332.3451523-2-thierry.reding@gmail.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
4 months agoMerge tag 'tegra-for-6.15-soc' of https://git.kernel.org/pub/scm/linux/kernel/git...
Arnd Bergmann [Wed, 19 Mar 2025 21:36:23 +0000 (22:36 +0100)] 
Merge tag 'tegra-for-6.15-soc' of https://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into soc/drivers

soc/tegra: Changes for v6.15-rc1

A simple cleanup patch to use str_yes_no() instead of an open-coded
version.

* tag 'tegra-for-6.15-soc' of https://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux:
  soc/tegra: pmc: Use str_enable_disable-like helpers

Link: https://lore.kernel.org/r/20250307162332.3451523-1-thierry.reding@gmail.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
5 months agodt-bindings: soc: samsung: exynos-usi: Drop unnecessary status from example
Krzysztof Kozlowski [Fri, 7 Mar 2025 08:13:41 +0000 (09:13 +0100)] 
dt-bindings: soc: samsung: exynos-usi: Drop unnecessary status from example

Device nodes in the examples are supposed to be enabled, so the schema
will be validated against them.  Keeping them disabled hides potential
errors.  Only one child of Samsung Exynos USI device node should be
enabled.  The node in the example already selected 'USI_MODE_UART', so
enable the serial node while keeping second - I2C - disabled.

Link: https://lore.kernel.org/r/20250307081341.35197-1-krzysztof.kozlowski@linaro.org
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
5 months agofirmware: tegra: bpmp: Fix typo in bpmp-abi.h
Zhu Jun [Mon, 18 Nov 2024 02:29:28 +0000 (18:29 -0800)] 
firmware: tegra: bpmp: Fix typo in bpmp-abi.h

The word 'traget' is wrong, so fix it.

Signed-off-by: Zhu Jun <zhujun2@cmss.chinamobile.com>
Link: https://lore.kernel.org/r/20241118022928.11305-1-zhujun2@cmss.chinamobile.com
Signed-off-by: Thierry Reding <treding@nvidia.com>
5 months agosoc/tegra: pmc: Use str_enable_disable-like helpers
Krzysztof Kozlowski [Tue, 14 Jan 2025 20:36:38 +0000 (21:36 +0100)] 
soc/tegra: pmc: Use str_enable_disable-like helpers

Replace ternary (condition ? "enable" : "disable") syntax with helpers
from string_choices.h because:
1. Simple function call with one argument is easier to read.  Ternary
   operator has three arguments and with wrapping might lead to quite
   long code.
2. Is slightly shorter thus also easier to read.
3. It brings uniformity in the text - same string.
4. Allows deduping by the linker, which results in a smaller binary
   file.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20250114203638.1013670-1-krzysztof.kozlowski@linaro.org
Signed-off-by: Thierry Reding <treding@nvidia.com>
5 months agosoc: samsung: include linux/array_size.h where needed
Arnd Bergmann [Wed, 5 Mar 2025 21:14:02 +0000 (22:14 +0100)] 
soc: samsung: include linux/array_size.h where needed

This does not necessarily get included through asm/io.h:

drivers/soc/samsung/exynos3250-pmu.c:120:18: error: use of undeclared identifier 'ARRAY_SIZE'
  120 |         for (i = 0; i < ARRAY_SIZE(exynos3250_list_feed); i++) {
      |                         ^
drivers/soc/samsung/exynos5250-pmu.c:162:18: error: use of undeclared identifier 'ARRAY_SIZE'
  162 |         for (i = 0; i < ARRAY_SIZE(exynos5_list_both_cnt_feed); i++) {
      |                         ^

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20250305211446.43772-1-arnd@kernel.org
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
5 months agoMerge tag 'mtk-soc-for-v6.15' of https://git.kernel.org/pub/scm/linux/kernel/git...
Arnd Bergmann [Thu, 6 Mar 2025 16:22:07 +0000 (17:22 +0100)] 
Merge tag 'mtk-soc-for-v6.15' of https://git.kernel.org/pub/scm/linux/kernel/git/mediatek/linux into soc/drivers

MediaTek driver updates for v6.15

This adds entries for new and missing SoCs in the MediaTek SoCInfo
driver (MT8370AV/AZA, MT8390AV/AZA) and an extra entry for a new
revision of the MT8395AV/ZA SoC.

The MediaTek SoCInfo driver also gets its SoC attribute information
restructured: now the family, machine and soc_id fields are correctly
populated.

MT8188 gains support for the secondary Display Parallel Interface
used for HDMI, and for the Display Stream Compression component
routing through mmsys and mutex tables.

All of the MMSYS drivers get an important overhaul: it was found that,
in multiple cases, the tables contained wrong mask/value pairs, hence
those were doing either nothing or breaking routings.
The mmsys tables were converted to use a newly introduced macro that
will perform a compile time check, making sure that each table entry's
value fits in the declared register mask.

Thanks to the new macro, multiple MediaTek SoCs got multiple fixes in
their MMSYS tables, addressing issues that were severely impacting the
functionality of the display controller pipelines.

* tag 'mtk-soc-for-v6.15' of https://git.kernel.org/pub/scm/linux/kernel/git/mediatek/linux:
  soc: mediatek: mtk-socinfo: Add extra entry for MT8395AV/ZA Genio 1200
  soc: mediatek: mt8188-mmsys: Add support for DSC on VDO0
  soc: mediatek: mmsys: Migrate all tables to MMSYS_ROUTE() macro
  soc: mediatek: mt8365-mmsys: Fix routing table masks and values
  soc: mediatek: mt8167-mmsys: Fix missing regval in all entries
  soc: mediatek: mt8188-mmsys: Migrate to MMSYS_ROUTE() macro
  soc: mediatek: mtk-mmsys: Add compile time check for mmsys routes
  soc: mediatek: mtk-mmsys: Fix MT8188 VDO1 DPI1 output selection
  soc: mediatek: mtk-mutex: Add DPI1 SOF/EOF to MT8188 mutex tables
  soc: mediatek: mtk-socinfo: Avoid using machine attribute in SoC detection log
  soc: mediatek: mtk-socinfo: Add entry for MT8390AV/AZA Genio 700
  soc: mediatek: mtk-socinfo: Add entry for MT8370AV/AZA Genio 510
  soc: mediatek: mtk-socinfo: Restructure SoC attribute information

Link: https://lore.kernel.org/r/20250306113540.148342-2-angelogioacchino.delregno@collabora.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
5 months agofirmware: arm_scmi: use ioread64() instead of ioread64_hi_lo()
Arnd Bergmann [Tue, 4 Mar 2025 14:43:34 +0000 (15:43 +0100)] 
firmware: arm_scmi: use ioread64() instead of ioread64_hi_lo()

The scmi_common_fastchannel_db_ring() function calls either ioread64()
or ioread64_hi_lo() depending on whether it is compiler for 32-bit
or 64-bit architectures.

The same logic is used to define ioread64() itself in the
linux/io-64-nonatomic-hi-lo.h header file, so the special case
is not really needed.

The behavior here should not change at all.

Fixes: 6f9ea4dabd2d ("firmware: arm_scmi: Generalize the fast channel support")
Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
Link: https://lore.kernel.org/r/20250304144346.1025658-1-arnd@kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
5 months agoMerge tag 'ffa-updates-6.15' of https://git.kernel.org/pub/scm/linux/kernel/git/sudee...
Arnd Bergmann [Thu, 6 Mar 2025 16:19:45 +0000 (17:19 +0100)] 
Merge tag 'ffa-updates-6.15' of https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into soc/drivers

Arm FF-A updates for v6.15

This update primarily focuses on FF-A framework notification support
along with other improvements, including UUID handling enhancements
and various fixes.

1. FF-A framework notification upport

    - Adds support for multiple UUIDs per partition to register individual
      SRI callbacks.
    - Handles Rx buffer full framework notifications and provides a general
      interface for future extensions.

2. Improved multiple UUID/services per-partition handling

    - Adds support for UUID passing in FFA_MSG_SEND2, improving multiple
      UUID/service support in the driver.
    - Introduces a helper function to check whether a partition can
      receive REQUEST2 messages.

3. Partition handling generic improvements

    - Implements device unregistration for better partition cleanup.
    - Improves handling of the host partition presence in partition info.

4. FF-A version updates

    - Upgrades the driver version to FF-A v1.2.
    - Rejects major versions higher than the driver version as incompatible.

5. Big-Endian support fixes

    - Fixes big-endian issues in:
        __ffa_partition_info_regs_get()
        __ffa_partition_info_get()
    - Big-endian support is still incomplete, and only these changes can
      be verified without additional application/testing updates at the
      moment. We can discover all the partitions correctly with big-endian
      kernel now.

6. Miscellaneous fixes

    - Fixes function prototype misalignments in: sync_send_receive{,2}
    - Adds explicit type casting for return values from: FFA_VERSION
      and NOTIFICATION_INFO_GET
    - Corrects vCPU list parsing in ffa_notification_info_get().

7. UUID management in the driver and DMA mask updates

    - Replaces UUID buffer with the standard UUID format in ffa_partition_info
      structure.
    - Fixes a typo in some FF-A bus macros.
    - Sets dma_mask for FF-A devices.

In short, this update enhances notification handling, UUID support, and
overall robustness of the FF-A driver while addressing multiple fixes
and cleanups.

* tag 'ffa-updates-6.15' of https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux: (23 commits)
  firmware: arm_ffa: Set dma_mask for ffa devices
  firmware: arm_ffa: Skip the first/partition ID when parsing vCPU list
  firmware: arm_ffa: Explicitly cast return value from NOTIFICATION_INFO_GET
  firmware: arm_ffa: Explicitly cast return value from FFA_VERSION before comparison
  firmware: arm_ffa: Handle ffa_notification_get correctly at virtual FF-A instance
  firmware: arm_ffa: Allow multiple UUIDs per partition to register SRI callback
  firmware: arm_ffa: Add support for handling framework notifications
  firmware: arm_ffa: Add support for {un,}registration of framework notifications
  firmware: arm_ffa: Stash ffa_device instead of notify_type in notifier_cb_info
  firmware: arm_ffa: Refactoring to prepare for framework notification support
  firmware: arm_ffa: Remove unnecessary declaration of ffa_partitions_cleanup()
  firmware: arm_ffa: Reject higher major version as incompatible
  firmware: arm_ffa: Upgrade FF-A version to v1.2 in the driver
  firmware: arm_ffa: Add support for passing UUID in FFA_MSG_SEND2
  firmware: arm_ffa: Helper to check if a partition can receive REQUEST2 messages
  firmware: arm_ffa: Unregister the FF-A devices when cleaning up the partitions
  firmware: arm_ffa: Handle the presence of host partition in the partition info
  firmware: arm_ffa: Refactor addition of partition information into XArray
  firmware: arm_ffa: Fix big-endian support in __ffa_partition_info_regs_get()
  firmware: arm_ffa: Fix big-endian support in __ffa_partition_info_get()
  ...

Link: https://lore.kernel.org/r/20250304105928.432997-1-sudeep.holla@arm.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
5 months agoMerge tag 'scmi-updates-6.15' of https://git.kernel.org/pub/scm/linux/kernel/git...
Arnd Bergmann [Thu, 6 Mar 2025 16:18:49 +0000 (17:18 +0100)] 
Merge tag 'scmi-updates-6.15' of https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into soc/drivers

Arm SCMI updates for v6.15

Couple of updates around the flexibility in SCMI device names and
addition of name, protocol id attributes and modalias for SCMI
devices in the sysfs.

Currently, in the scmi_protocol_device_request() function, SCMI device
names ust be unique across all protocols. However, this constraint is
being relaxed, allowing devices in different protocols to share the
same name. The change aims to provide more flexibility in naming devices
across various protocols.

Two attributes: name and protocol ID is being added to the SCMI device
in the sysfs along with the support for the modalias. These attributes
aim to enhance device identification and management.

* tag 'scmi-updates-6.15' of https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux:
  firmware: arm_scmi: Emit modalias for SCMI devices
  firmware: arm_scmi: Add name and protocol id attributes
  firmware: arm_scmi: Relax duplicate name constraint across protocol ids

Link: https://lore.kernel.org/r/20250304105915.432967-1-sudeep.holla@arm.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
5 months agoMerge tag 'smccc-update-6.15' of https://git.kernel.org/pub/scm/linux/kernel/git...
Arnd Bergmann [Thu, 6 Mar 2025 16:16:57 +0000 (17:16 +0100)] 
Merge tag 'smccc-update-6.15' of https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into soc/drivers

Arm SMCCC update for v6.15

Just a single update introducing the support for the optional SOC_ID
name string from the Arm SMCCC v1.6 specification.

If the SOC_ID name string is implemented, the machine field of the SoC
Device Attributes will reflect it.

The original intent of SOC_ID was to provide a JEP-106 code for the SiP
and the SoC revision to uniquely identify the SoC. However, there has
been a request to add this optional name so that SoC firmware can
directly provide the SoC name to the OS.

This change avoids the need for frequent updates to various tools that
would otherwise require maintaining hardcoded model/machine name tables
for new SoCs.

* tag 'smccc-update-6.15' of https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux:
  firmware: smccc: Support optional Arm SMCCC SOC_ID name

Link: https://lore.kernel.org/r/20250304105845.432813-1-sudeep.holla@arm.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
5 months agoMerge tag 'asahi-soc-rtkit-6.15' of https://github.com/AsahiLinux/linux into soc...
Arnd Bergmann [Thu, 6 Mar 2025 16:14:51 +0000 (17:14 +0100)] 
Merge tag 'asahi-soc-rtkit-6.15' of https://github.com/AsahiLinux/linux into soc/drivers

Apple SoC RTKit IPC library updates for 6.15:

- Additional logging for errors
- A few minor improvements and bugfixes required for drivers that are
  yet to be upstreamed

* tag 'asahi-soc-rtkit-6.15' of https://github.com/AsahiLinux/linux:
  soc: apple: rtkit: Cut syslog messages after the first '\0'
  soc: apple: rtkit: Use high prio work queue
  soc: apple: rtkit: Implement OSLog buffers properly
  soc: apple: rtkit: Add and use PWR_STATE_INIT instead of _ON
  soc: apple: rtkit: Fix use-after-free in apple_rtkit_crashlog_rx()
  soc: apple: rtkit: Pass the crashlog to the crashed() callback
  soc: apple: rtkit: Check & log more failures

Link: https://lore.kernel.org/r/20250302113842.58092-1-sven@svenpeter.dev
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
5 months agoMerge tag 'renesas-drivers-for-v6.15-tag1' of https://git.kernel.org/pub/scm/linux...
Arnd Bergmann [Thu, 6 Mar 2025 16:01:02 +0000 (17:01 +0100)] 
Merge tag 'renesas-drivers-for-v6.15-tag1' of https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel into soc/drivers

Renesas driver updates for v6.15

  - Add a driver for the System Controller on RZ/G3S, RZ/G3E, and
    RZ/V2H.

* tag 'renesas-drivers-for-v6.15-tag1' of https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel:
  soc: renesas: r9a09g057-sys: Add a callback to print SoC-specific extra features
  soc: renesas: rz-sysc: Move RZ/V2H SoC detection to the SYS driver
  soc: renesas: rz-sysc: Add support for RZ/G3E family
  soc: renesas: rz-sysc: Move RZ/G3S SoC detection to the SYSC driver
  soc: renesas: Add SYSC driver for Renesas RZ family

Link: https://lore.kernel.org/r/cover.1740156741.git.geert+renesas@glider.be
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
5 months agosoc: mediatek: mtk-socinfo: Add extra entry for MT8395AV/ZA Genio 1200
Louis-Alexis Eyraud [Thu, 20 Feb 2025 15:02:09 +0000 (16:02 +0100)] 
soc: mediatek: mtk-socinfo: Add extra entry for MT8395AV/ZA Genio 1200

The Mediatek Genio 1200 EVK P1V2 board has a different socinfo match
for MT8395 SoC (commercial name Genio 1200), so add it the driver.

Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20250220-mtk-socinfo-genio-1200-evk-v1-1-a683ad028bc5@collabora.com
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
5 months agosoc: mediatek: mt8188-mmsys: Add support for DSC on VDO0
AngeloGioacchino Del Regno [Wed, 12 Feb 2025 10:00:12 +0000 (11:00 +0100)] 
soc: mediatek: mt8188-mmsys: Add support for DSC on VDO0

Add routing paths to support Display Stream Compression on the
VDOSYS0 pipelines ending with DSI or DisplayPort (DP_INTF).

Link: https://lore.kernel.org/r/20250212100012.33001-9-angelogioacchino.delregno@collabora.com
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
5 months agosoc: mediatek: mmsys: Migrate all tables to MMSYS_ROUTE() macro
AngeloGioacchino Del Regno [Wed, 12 Feb 2025 10:00:11 +0000 (11:00 +0100)] 
soc: mediatek: mmsys: Migrate all tables to MMSYS_ROUTE() macro

Now that all of the mmsys routing tables have been fixed,
migrate all of them to use the MMSYS_ROUTE() macro: this
will make sure that future additions to any of the tables
for the currently supported SoCs are compile-time sanity
checked, greatly reducing room for (way too common) mistakes.

Link: https://lore.kernel.org/r/20250212100012.33001-8-angelogioacchino.delregno@collabora.com
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
5 months agosoc: mediatek: mt8365-mmsys: Fix routing table masks and values
AngeloGioacchino Del Regno [Wed, 12 Feb 2025 10:00:10 +0000 (11:00 +0100)] 
soc: mediatek: mt8365-mmsys: Fix routing table masks and values

The mmsys driver reads the routing table and writes to the
hardware `val & mask`, but multiple entries in the mmsys
routing table for the MT8365 SoC are setting a 0x0 mask:
this effectively writes .. nothing .. to the hardware.

That would never work, and if the display controller was
actually working with the mmsys doing no routing at all,
that was only because the bootloader was correctly setting
the display controller routing registers before booting the
kernel, and the mmsys was never reset.

Make this table to actually set the routing by adding the
correct register masks to it.

While at it, also change MOUT val definitions to BIT(x), as
the MOUT registers are effectively checking for each bit to
enable output to the corresponding HW.
Please note that, for this SoC, only the MOUT registers are
checking bits (as those can enable multiple outputs), while
the others are purely reading a number to select an input.

Fixes: bc3fc5c05100 ("soc: mediatek: mmsys: add MT8365 support")
Link: https://lore.kernel.org/r/20250212100012.33001-7-angelogioacchino.delregno@collabora.com
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
5 months agosoc: mediatek: mt8167-mmsys: Fix missing regval in all entries
AngeloGioacchino Del Regno [Wed, 12 Feb 2025 10:00:09 +0000 (11:00 +0100)] 
soc: mediatek: mt8167-mmsys: Fix missing regval in all entries

The mmsys routing table for this SoC was effectively missing
initialization of the val variable of struct mtk_mmsys_routes:
this means that `val` was incorrectly initialized to zero,
hence the registers were wrongly initialized.

Add the required regval to all of the entries of the routing
table for this SoC to fix display controller functionality.

Fixes: 060f7875bd23 ("soc: mediatek: mmsys: Add support for MT8167 SoC")
Link: https://lore.kernel.org/r/20250212100012.33001-6-angelogioacchino.delregno@collabora.com
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
5 months agosoc: mediatek: mt8188-mmsys: Migrate to MMSYS_ROUTE() macro
AngeloGioacchino Del Regno [Wed, 12 Feb 2025 10:00:08 +0000 (11:00 +0100)] 
soc: mediatek: mt8188-mmsys: Migrate to MMSYS_ROUTE() macro

Change the initialization data in the arrays of structure
mtk_mmsys_routes to make use of the MMSYS_ROUTE() macro:
this will make sure that each array entry's SEL value fits
in its corresponding register mask with a compile time check.

Link: https://lore.kernel.org/r/20250212100012.33001-5-angelogioacchino.delregno@collabora.com
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
5 months agosoc: mediatek: mtk-mmsys: Add compile time check for mmsys routes
AngeloGioacchino Del Regno [Wed, 12 Feb 2025 10:00:07 +0000 (11:00 +0100)] 
soc: mediatek: mtk-mmsys: Add compile time check for mmsys routes

Every MediaTek SoC with multimedia capabilities has an array of
structure mtk_mmsys_routes that defines a multimedia connection
between hardware components.

This connection is activated by writing a (masked) value in each
specific register, and the association between from->to path and
value to write is expressed as an entry in that array.

Failing to set the right path does not give any meaningful error
and makes things to simply not work as the data will either not
be retrieved from the right input port, or will be written to
the wrong output port (or both): since a misconfiguration may
effectively still be a possibly correct configuration at the HW
level, this may be only giving side effects in terms of simply
getting no functionality but, again, no errors.

In order to reduce room for mistakes in declarations of the
mmsys routes, add a macro that compile-time checks that the
provided value does at least fit in the register mask.

Link: https://lore.kernel.org/r/20250212100012.33001-4-angelogioacchino.delregno@collabora.com
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
5 months agosoc: mediatek: mtk-mmsys: Fix MT8188 VDO1 DPI1 output selection
AngeloGioacchino Del Regno [Wed, 12 Feb 2025 10:00:06 +0000 (11:00 +0100)] 
soc: mediatek: mtk-mmsys: Fix MT8188 VDO1 DPI1 output selection

The VDO1_MERGE4 hardware (merge5 software component) should be
set to enable output to DPI1_SEL by setting BIT(2) but, despite
the intention being exactly that, this won't work because the
declared register mask is wrong as it is set as GENMASK(1, 0).

Register MERGE4_MOUT_EN in VDO1 has four used bits [3, 0] so
fix the mask to reflect that.
That, in turn, allows the mmsys driver to actually set BIT(2)
in this register, fixing the MERGE4 output to DPI1 selection.

Fixes: c0349314d5a0 ("soc: mediatek: Support MT8188 VDOSYS1 in mtk-mmsys")
Link: https://lore.kernel.org/r/20250212100012.33001-3-angelogioacchino.delregno@collabora.com
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
5 months agosoc: mediatek: mtk-mutex: Add DPI1 SOF/EOF to MT8188 mutex tables
AngeloGioacchino Del Regno [Wed, 12 Feb 2025 10:00:05 +0000 (11:00 +0100)] 
soc: mediatek: mtk-mutex: Add DPI1 SOF/EOF to MT8188 mutex tables

MT8188 uses DPI1 to output to the HDMI controller: add the
Start of Frame and End of Frame configuration for the DPI1
IP to the tables to unblock generation and sending of these
signals to the GCE.

Link: https://lore.kernel.org/r/20250212100012.33001-2-angelogioacchino.delregno@collabora.com
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
5 months agosoc: mediatek: mtk-socinfo: Avoid using machine attribute in SoC detection log
Louis-Alexis Eyraud [Fri, 21 Feb 2025 11:04:02 +0000 (12:04 +0100)] 
soc: mediatek: mtk-socinfo: Avoid using machine attribute in SoC detection log

The recently introduced SoC attribute info rework avoided modifying the
machine attribut but still used it in the log message on successful SoC
matching. It leads to print a confusing log about a board-related info
(read from devicetree) and not about the matched SoC:
```
mtk-socinfo mtk-socinfo.0.auto: MediaTek MediaTek Genio-510 EVK SoC
  detected
```

So, fix the dev_info format to display SoC family and name attribute
instead.
```
mtk-socinfo mtk-socinfo.0.auto: MediaTek Genio 510 (MT8370) SoC detected.
```

Fixes: da77c2d3d06c ("soc: mediatek: mtk-socinfo: Restructure SoC attribute information")
Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
Reviewed-by: Fei Shao <fshao@chromium.org>
Tested-by: Fei Shao <fshao@chromium.org>
Link: https://lore.kernel.org/r/20250221-mtk-socinfo-fix-print-v1-1-20500f30ef66@collabora.com
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
5 months agosoc: samsung: exynos-chipid: add support for exynos7870
Kaustabh Chakraborty [Fri, 28 Feb 2025 19:46:51 +0000 (01:16 +0530)] 
soc: samsung: exynos-chipid: add support for exynos7870

Add the product ID of Exynos7870 (S5E7870) to the existing list.

Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
Link: https://lore.kernel.org/r/20250301-exynos7870-v4-3-2925537f9b2a@disroot.org
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
5 months agodt-bindings: soc: samsung: exynos-pmu: add exynos7870-pmu compatible
Kaustabh Chakraborty [Fri, 28 Feb 2025 19:46:49 +0000 (01:16 +0530)] 
dt-bindings: soc: samsung: exynos-pmu: add exynos7870-pmu compatible

Document the compatible string for the Exynos7870 PMU. It's compatible
with the Exynos7 PMU design. It handles syscon reboot, syscon reboot mode,
as well as other system control registers (i.e registers for the USB PHY).

Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
Link: https://lore.kernel.org/r/20250301-exynos7870-v4-1-2925537f9b2a@disroot.org
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
5 months agofirmware: smccc: Support optional Arm SMCCC SOC_ID name
Paul Benoit [Wed, 19 Feb 2025 00:59:32 +0000 (16:59 -0800)] 
firmware: smccc: Support optional Arm SMCCC SOC_ID name

Issue Number 1.6 of the Arm SMC Calling Convention introduces an optional
SOC_ID name string.  If implemented, point the 'machine' field of the SoC
Device Attributes at this string so that it will appear under
/sys/bus/soc/devices/soc0/machine.

On Arm SMC compliant SoCs, this will allow things like 'lscpu' to
eventually get a SoC provider model name from there rather than each
tool/utility needing to get a possibly inconsistent, obsolete, or incorrect
model/machine name from its own hardcoded model/machine name table.

Signed-off-by: Paul Benoit <paul@os.amperecomputing.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Lorenzo Pieralisi <lpieralisi@kernel.org>
Cc: Sudeep Holla <sudeep.holla@arm.com>
Cc: linux-arm-kernel@lists.infradead.org
Acked-by: Mark Rutland <mark.rutland@arm.com>
Message-Id: <20250219005932.3466-1-paul@os.amperecomputing.com>
(sudeep.holla: Dropped regsize variable and used 8 instead as Mark suggested)
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
5 months agosoc: apple: rtkit: Cut syslog messages after the first '\0'
Janne Grunau [Wed, 26 Feb 2025 19:00:06 +0000 (19:00 +0000)] 
soc: apple: rtkit: Cut syslog messages after the first '\0'

Certain messages from DCP contain NUL bytes in the random data after the
NUL terminated syslog message. Since the syslog message ends with '\n'
this results in a dev_info() message terminated with two newlines and an
empty printed line in the kernel log.

Signed-off-by: Janne Grunau <j@jannau.net>
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Link: https://lore.kernel.org/r/20250226-apple-soc-misc-v2-4-c3ec37f9021b@svenpeter.dev
Signed-off-by: Sven Peter <sven@svenpeter.dev>
5 months agosoc: apple: rtkit: Use high prio work queue
Janne Grunau [Wed, 26 Feb 2025 19:00:05 +0000 (19:00 +0000)] 
soc: apple: rtkit: Use high prio work queue

rtkit messages as communication with the DCP firmware for framebuffer
swaps or input events are time critical so use WQ_HIGHPRI to prevent
user space CPU load to increase latency.
With kwin_wayland 6's explicit sync mode user space load was able to
delay the IOMFB rtkit communication enough to miss vsync for surface
swaps. Minimal test scenario is constantly resizing a glxgears
Xwayland window.

Signed-off-by: Janne Grunau <j@jannau.net>
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Link: https://lore.kernel.org/r/20250226-apple-soc-misc-v2-3-c3ec37f9021b@svenpeter.dev
Signed-off-by: Sven Peter <sven@svenpeter.dev>
5 months agosoc: apple: rtkit: Implement OSLog buffers properly
Hector Martin [Wed, 26 Feb 2025 19:00:04 +0000 (19:00 +0000)] 
soc: apple: rtkit: Implement OSLog buffers properly

Apparently nobody can figure out where the old logic came from, but it
seems like it has never been actually used on any supported firmware to
this day. OSLog buffers were apparently never requested.

But starting with 13.3, we actually need this implemented properly for
MTP (and later AOP) to work, so let's actually do that.

Signed-off-by: Hector Martin <marcan@marcan.st>
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Link: https://lore.kernel.org/r/20250226-apple-soc-misc-v2-2-c3ec37f9021b@svenpeter.dev
Signed-off-by: Sven Peter <sven@svenpeter.dev>
5 months agosoc: apple: rtkit: Add and use PWR_STATE_INIT instead of _ON
Janne Grunau [Wed, 26 Feb 2025 19:00:03 +0000 (19:00 +0000)] 
soc: apple: rtkit: Add and use PWR_STATE_INIT instead of _ON

This state is needed to wake the dcp IOP after m1n1 shut it down
and works for all other co-processors as well.

Signed-off-by: Janne Grunau <j@jannau.net>
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Link: https://lore.kernel.org/r/20250226-apple-soc-misc-v2-1-c3ec37f9021b@svenpeter.dev
Signed-off-by: Sven Peter <sven@svenpeter.dev>
5 months agofirmware: arm_ffa: Set dma_mask for ffa devices
Viresh Kumar [Fri, 17 Jan 2025 10:05:52 +0000 (15:35 +0530)] 
firmware: arm_ffa: Set dma_mask for ffa devices

Set dma_mask for FFA devices, otherwise DMA allocation using the device pointer
lead to following warning:

WARNING: CPU: 1 PID: 1 at kernel/dma/mapping.c:597 dma_alloc_attrs+0xe0/0x124

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Message-Id: <e3dd8042ac680bd74b6580c25df855d092079c18.1737107520.git.viresh.kumar@linaro.org>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
5 months agofirmware: arm_ffa: Skip the first/partition ID when parsing vCPU list
Sudeep Holla [Sun, 23 Feb 2025 21:39:09 +0000 (21:39 +0000)] 
firmware: arm_ffa: Skip the first/partition ID when parsing vCPU list

The FF-A notification id list received in response to the call
FFA_NOTIFICATION_INFO_GET is encoded as: partition ID followed by 0 or
more vCPU ID. The count includes all of them.

Fix the issue by skipping the first/partition ID so that only the list
of vCPU IDs are processed correctly for a given partition ID. The first/
partition ID is read before the start of the loop.

Fixes: 3522be48d82b ("firmware: arm_ffa: Implement the NOTIFICATION_INFO_GET interface")
Reported-by: Andrei Homescu <ahomescu@google.com>
Message-Id: <20250223213909.1197786-1-sudeep.holla@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
5 months agofirmware: arm_ffa: Explicitly cast return value from NOTIFICATION_INFO_GET
Sudeep Holla [Fri, 21 Feb 2025 09:56:32 +0000 (09:56 +0000)] 
firmware: arm_ffa: Explicitly cast return value from NOTIFICATION_INFO_GET

The return value ret.a2 is of type unsigned long and FFA_RET_NO_DATA is
a negative value.

Since the return value from the firmware can be just 32-bit even on
64-bit systems as FFA specification mentions it as int32 error code in
w0 register, explicitly casting to s32 ensures correct sign interpretation
when comparing against a signed error code FFA_RET_NO_DATA.

Without casting, comparison between unsigned long and a negative
constant could lead to unintended results due to type promotions.

Fixes: 3522be48d82b ("firmware: arm_ffa: Implement the NOTIFICATION_INFO_GET interface")
Reported-by: Andrei Homescu <ahomescu@google.com>
Message-Id: <20250221095633.506678-2-sudeep.holla@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
5 months agofirmware: arm_ffa: Explicitly cast return value from FFA_VERSION before comparison
Sudeep Holla [Fri, 21 Feb 2025 09:56:31 +0000 (09:56 +0000)] 
firmware: arm_ffa: Explicitly cast return value from FFA_VERSION before comparison

The return value ver.a0 is unsigned long type and FFA_RET_NOT_SUPPORTED
is a negative value.

Since the return value from the firmware can be just 32-bit even on
64-bit systems as FFA specification mentions it as int32 error code in
w0 register, explicitly casting to s32 ensures correct sign interpretation
when comparing against a signed error code FFA_RET_NOT_SUPPORTED.

Without casting, comparison between unsigned long and a negative
constant could lead to unintended results due to type promotions.

Fixes: 3bbfe9871005 ("firmware: arm_ffa: Add initial Arm FFA driver support")
Reported-by: Andrei Homescu <ahomescu@google.com>
Message-Id: <20250221095633.506678-1-sudeep.holla@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
5 months agodt-bindings: hwinfo: samsung,exynos-chipid: add exynos7870-chipid compatible
Kaustabh Chakraborty [Tue, 18 Feb 2025 19:03:11 +0000 (00:33 +0530)] 
dt-bindings: hwinfo: samsung,exynos-chipid: add exynos7870-chipid compatible

Document the compatible string "samsung,exynos7870-chipid". The
registers are entirely compatible with "samsung,exynos4210-chipid".

Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
Link: https://lore.kernel.org/r/20250219-exynos7870-v3-1-e384fb610cad@disroot.org
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
5 months agosoc: renesas: r9a09g057-sys: Add a callback to print SoC-specific extra features
John Madieu [Tue, 28 Jan 2025 03:13:42 +0000 (04:13 +0100)] 
soc: renesas: r9a09g057-sys: Add a callback to print SoC-specific extra features

Some RZ/V2H SoC variants feature a Mali-G31 (GPU) and/or a Mali-C55
(ISP) IP(s).  Detect and inform about their presence during SoC
identification.  Also detect PLL frequency and warn in case of mismatch.

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com>
Link: https://lore.kernel.org/20250128031342.52675-6-john.madieu.xa@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
5 months agosoc: renesas: rz-sysc: Move RZ/V2H SoC detection to the SYS driver
John Madieu [Tue, 28 Jan 2025 03:13:41 +0000 (04:13 +0100)] 
soc: renesas: rz-sysc: Move RZ/V2H SoC detection to the SYS driver

As per the other SoC variant of the same family, the system controller
provides SoC ID in its own registers.

Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/20250128031342.52675-5-john.madieu.xa@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
5 months agosoc: renesas: rz-sysc: Add support for RZ/G3E family
John Madieu [Tue, 28 Jan 2025 03:13:40 +0000 (04:13 +0100)] 
soc: renesas: rz-sysc: Add support for RZ/G3E family

Add SoC detection support for the RZ/G3E SoC.  Also add support for
detecting the number of cores and the ETHOS-U55 NPU, and also detect PLL
mismatch for SW settings other than 1.7GHz.

Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/20250128031342.52675-4-john.madieu.xa@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
5 months agosoc: renesas: rz-sysc: Move RZ/G3S SoC detection to the SYSC driver
Claudiu Beznea [Tue, 28 Jan 2025 03:13:39 +0000 (04:13 +0100)] 
soc: renesas: rz-sysc: Move RZ/G3S SoC detection to the SYSC driver

Now that we have SoC detection in the RZ SYSC driver, move the RZ/G3S
SoC detection to it. The SYSC provides SoC ID in its own registers.

Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com>
Link: https://lore.kernel.org/20250128031342.52675-3-john.madieu.xa@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
5 months agosoc: renesas: Add SYSC driver for Renesas RZ family
Claudiu Beznea [Tue, 28 Jan 2025 03:13:38 +0000 (04:13 +0100)] 
soc: renesas: Add SYSC driver for Renesas RZ family

The RZ/G3S system controller (SYSC) has various registers that control
different functionalities.  One of the exposed register offers
information about the SoC identification.

Add a driver that identifies the SoC.  Later the driver will be extended
with other functionalities.

Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/20250128031342.52675-2-john.madieu.xa@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
5 months agosoc: samsung: exynos-chipid: add exynos2200 SoC support
Ivaylo Ivanov [Sat, 15 Feb 2025 11:27:16 +0000 (13:27 +0200)] 
soc: samsung: exynos-chipid: add exynos2200 SoC support

Add EXYNOS2200 information to soc_ids tables. This SoC product id
is "0xE9925000".

Signed-off-by: Ivaylo Ivanov <ivo.ivanov.ivanov1@gmail.com>
Link: https://lore.kernel.org/r/20250215112716.159110-5-ivo.ivanov.ivanov1@gmail.com
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
5 months agodt-bindings: hwinfo: samsung,exynos-chipid: add exynos2200 compatible
Ivaylo Ivanov [Sat, 15 Feb 2025 11:27:15 +0000 (13:27 +0200)] 
dt-bindings: hwinfo: samsung,exynos-chipid: add exynos2200 compatible

Add "samsung,exynos2200-chipid" compatible string to binding document.
Since Samsung, as usual, likes reusing devices from older designs, use
the samsung,exynos850-chipid compatible.

Signed-off-by: Ivaylo Ivanov <ivo.ivanov.ivanov1@gmail.com>
Link: https://lore.kernel.org/r/20250215112716.159110-4-ivo.ivanov.ivanov1@gmail.com
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
5 months agodt-bindings: soc: samsung: exynos-pmu: add exynos2200 compatible
Ivaylo Ivanov [Sat, 15 Feb 2025 11:27:14 +0000 (13:27 +0200)] 
dt-bindings: soc: samsung: exynos-pmu: add exynos2200 compatible

Add exynos2200-pmu compatible to the bindings documentation. Since
Samsung, as usual, reuses devices from older designs, use the
samsung,exynos7-pmu compatible.

Signed-off-by: Ivaylo Ivanov <ivo.ivanov.ivanov1@gmail.com>
Link: https://lore.kernel.org/r/20250215112716.159110-3-ivo.ivanov.ivanov1@gmail.com
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
5 months agodt-bindings: soc: samsung: exynos-sysreg: add sysreg compatibles for exynos2200
Ivaylo Ivanov [Sat, 15 Feb 2025 11:27:13 +0000 (13:27 +0200)] 
dt-bindings: soc: samsung: exynos-sysreg: add sysreg compatibles for exynos2200

Add dedicated compatibles for 5 of Exynos2200's sysreg controllers to
the documentation.

Signed-off-by: Ivaylo Ivanov <ivo.ivanov.ivanov1@gmail.com>
Link: https://lore.kernel.org/r/20250215112716.159110-2-ivo.ivanov.ivanov1@gmail.com
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
5 months agosoc: apple: rtkit: Fix use-after-free in apple_rtkit_crashlog_rx()
Harshit Mogalapalli [Wed, 12 Feb 2025 08:58:53 +0000 (00:58 -0800)] 
soc: apple: rtkit: Fix use-after-free in apple_rtkit_crashlog_rx()

This code calls kfree(bfr); and then passes "bfr" to rtk->ops->crashed()
which is a use after free.  The ->crashed function pointer is implemented
by apple_nvme_rtkit_crashed() and it doesn't use the "bfr" pointer so
this doesn't cause a problem.  But it still looks sketchy as can be.

Fix this by moving kfree() after the last usage of bfr.

Fixes: bf8b4e49777d ("soc: apple: rtkit: Pass the crashlog to the crashed() callback")
Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
Reviewed-by: Eric Curtin <ecurtin@redhat.com>
Link: https://lore.kernel.org/r/20250212085853.1357906-1-harshit.m.mogalapalli@oracle.com
Signed-off-by: Sven Peter <sven@svenpeter.dev>
5 months agosoc: apple: rtkit: Pass the crashlog to the crashed() callback
Asahi Lina [Sun, 2 Feb 2025 13:48:47 +0000 (22:48 +0900)] 
soc: apple: rtkit: Pass the crashlog to the crashed() callback

Client drivers might want a copy of the crashlog to stash into a
devcoredump blob. Since device memory management can be very variable,
the actual devcoredump implementation is left to client drivers. Pass
the raw crashlog buffer to the client callback so it can use it if
desired.

Signed-off-by: Asahi Lina <lina@asahilina.net>
Reviewed-by: Jens Axboe <axboe@kernel.dk>
Link: https://lore.kernel.org/r/20250202-rtkit-crashdump-v1-1-9d38615b4e12@asahilina.net
Signed-off-by: Sven Peter <sven@svenpeter.dev>
5 months agosoc: apple: rtkit: Check & log more failures
Asahi Lina [Tue, 11 Feb 2025 17:59:44 +0000 (12:59 -0500)] 
soc: apple: rtkit: Check & log more failures

Check and log the following failures:

* regular messages
* management messages
* failed buffer requests

This helps debugging.

Signed-off-by: Asahi Lina <lina@asahilina.net>
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Neal Gompa <neal@gompa.dev>
Link: https://lore.kernel.org/r/20250211-rtkit-more-logging-v1-1-93334e9c1c77@rosenzweig.io
Signed-off-by: Sven Peter <sven@svenpeter.dev>
5 months agosoc: mediatek: mtk-socinfo: Add entry for MT8390AV/AZA Genio 700
Louis-Alexis Eyraud [Mon, 13 Jan 2025 16:13:24 +0000 (17:13 +0100)] 
soc: mediatek: mtk-socinfo: Add entry for MT8390AV/AZA Genio 700

Add an entry for the MT8390 SoC with commercial name Genio 700.

Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20250113-mtk-socinfo_genio-510-700-v1-2-cf5112b325b7@collabora.com
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
5 months agosoc: mediatek: mtk-socinfo: Add entry for MT8370AV/AZA Genio 510
Louis-Alexis Eyraud [Mon, 13 Jan 2025 16:13:23 +0000 (17:13 +0100)] 
soc: mediatek: mtk-socinfo: Add entry for MT8370AV/AZA Genio 510

Add an entry for the MT8370 SoC with commercial name Genio 510.

Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20250113-mtk-socinfo_genio-510-700-v1-1-cf5112b325b7@collabora.com
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
5 months agosoc: mediatek: mtk-socinfo: Restructure SoC attribute information
Fei Shao [Thu, 19 Dec 2024 11:33:50 +0000 (19:33 +0800)] 
soc: mediatek: mtk-socinfo: Restructure SoC attribute information

So far, the MediaTek socinfo driver populates the SoC information as
follows:
  - family:  "MediaTek"
  - machine: "<marketing_name> (<soc_name>)"
      e.g.,  "Kompanio 1380 (MT8195)"
  - soc_id:  <null>

This approach has some drawbacks:
1.  "soc_id" can be used for showing the SoC name (e.g. "MT8195"), while
    it's currently unused.
2.  The newer socinfo API automatically populates the "machine"
    attribute with the model name from board DTS if unspecified, which
    we may want to preserve if possible.
3.  "machine" combines the marketing name and SoC name, making it
    trickier to parse. Ideally, the marketing name and SoC name should
    be in separate attributes so userspace to utilize them as needed.
4.  There's no guarantee that the marketing name will be announced along
    with the SoC name. If either is undetermined, the current design
    will result in a malformed "machine" output. This is observed on
    some newer MediaTek platforms, where the marketing name is still
    undetermined but the SoC information needs to be settled for device
    registration and validation before launch.

To address these points, this commit proposes a new theme to display the
SoC information:
  - family:  "MediaTek <marketing_name>"
      e.g.,  "MediaTek Kompanio 1380"
  - machine: "<dt_model_name>" (auto-populated)
      e.g.,  "Acer Tomato (rev1) board"
  - soc_id:  "<soc_name>"
      e.g.,  "MT8195"

Moreover, if the marketing name is not provided, the driver displays
"MediaTek" in the "family" attribute instead, consistent with the
previous behavior.

Restructure the way driver populates the SoC information as described
above.

Note that Mediatek-based Chromebooks are the primary consumers of this
socinfo driver, and Google has prepared corresponding userspace changes
to comply with this update, so the impact to userspace is controlled.

Signed-off-by: Fei Shao <fshao@chromium.org>
Link: https://lore.kernel.org/r/20241219113411.3999355-1-fshao@chromium.org
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
5 months agofirmware: arm_ffa: Handle ffa_notification_get correctly at virtual FF-A instance
Sudeep Holla [Mon, 17 Feb 2025 15:39:00 +0000 (15:39 +0000)] 
firmware: arm_ffa: Handle ffa_notification_get correctly at virtual FF-A instance

Currently it is assumed that the driver always calls ffa_notification_get()
at the NS physical FF-A instance to request the SPMC to return pending
SP or SPM Framework notifications. However, in order to support the driver
invoking ffa_notification_get() at virtual FF-A instance, we need to make
sure correct bits are enabled in the bitmaps enable flag.

It is expected to have hypervisor framework and VM notifications bitmap
to be zero at the non-secure physical FF-A instance.

Message-Id: <20250217-ffa_updates-v3-19-bd1d9de615e7@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
5 months agofirmware: arm_ffa: Allow multiple UUIDs per partition to register SRI callback
Sudeep Holla [Mon, 17 Feb 2025 15:38:59 +0000 (15:38 +0000)] 
firmware: arm_ffa: Allow multiple UUIDs per partition to register SRI callback

A partition can implement multiple UUIDs and currently we successfully
register each UUID service as a FF-A device. However when adding the
same partition info to the XArray which tracks the SRI callbacks more
than once, it fails.

In order to allow multiple UUIDs per partition to register SRI callbacks
the partition information stored in the XArray needs to be extended to
a listed list.

A function to remove the list of partition information in the XArray
is not added as there are no users at the time. All the partitions are
added at probe/initialisation and removed at cleanup stage.

Tested-by: Viresh Kumar <viresh.kumar@linaro.org>
Message-Id: <20250217-ffa_updates-v3-18-bd1d9de615e7@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
5 months agofirmware: arm_ffa: Add support for handling framework notifications
Sudeep Holla [Mon, 17 Feb 2025 15:38:58 +0000 (15:38 +0000)] 
firmware: arm_ffa: Add support for handling framework notifications

Currently FF-A specification defines only one framework notification:
RX buffer full notification. This notification is signaled by the
partition manager during transmission of a partition message through
indirect messaging to,

1. Notify an endpoint that it has a pending message in its Rx buffer.
2. Inform the message receiver’s scheduler via the schedule receiver
   interrupt that the receiver must be run.

In response to an FFA_MSG_SEND2 invocation by a sender endpoint, the
framework performs the following actions after the message is copied
from the Tx buffer of the sender to the Rx buffer of the receiver:

1. The notification is pended in the framework notification bitmap of
   the receiver.
2. The partition manager of the endpoint that contains receiver’s
   scheduler pends the schedule receiver interrupt for this endpoint.

The receiver receives the notification and copies out the message from
its Rx buffer.

Tested-by: Viresh Kumar <viresh.kumar@linaro.org>
Message-Id: <20250217-ffa_updates-v3-17-bd1d9de615e7@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
5 months agofirmware: arm_ffa: Add support for {un,}registration of framework notifications
Sudeep Holla [Mon, 17 Feb 2025 15:38:57 +0000 (15:38 +0000)] 
firmware: arm_ffa: Add support for {un,}registration of framework notifications

Framework notifications are doorbells that are rung by the partition
managers to signal common events to an endpoint. These doorbells cannot
be rung by an endpoint directly. A partition manager can signal a
Framework notification in response to an FF-A ABI invocation by an
endpoint.

Two additional notify_ops interface is being added for any FF-A device/
driver to register and unregister for such a framework notifications.

Tested-by: Viresh Kumar <viresh.kumar@linaro.org>
Message-Id: <20250217-ffa_updates-v3-16-bd1d9de615e7@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
5 months agofirmware: arm_ffa: Stash ffa_device instead of notify_type in notifier_cb_info
Sudeep Holla [Mon, 17 Feb 2025 15:38:56 +0000 (15:38 +0000)] 
firmware: arm_ffa: Stash ffa_device instead of notify_type in notifier_cb_info

Currently, we store the type of the notification in the notifier_cb_info
structure that is put into the hast list to identify if the notification
block is for the secure partition or the non secure VM.

In order to support framework notifications to reuse the hash list and
to avoid creating one for each time, we need store the ffa_device pointer
itself as the same notification ID in framework notifications can be
registered by multiple FF-A devices.

Tested-by: Viresh Kumar <viresh.kumar@linaro.org>
Message-Id: <20250217-ffa_updates-v3-15-bd1d9de615e7@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
5 months agofirmware: arm_ffa: Refactoring to prepare for framework notification support
Sudeep Holla [Mon, 17 Feb 2025 15:38:55 +0000 (15:38 +0000)] 
firmware: arm_ffa: Refactoring to prepare for framework notification support

Currently, the framework notifications are not supported at all.
handle_notif_callbacks() doesn't handle them though it is called with
framework bitmap. Make that explicit by adding checks for the same.

Also, we need to further classify the framework notifications as Secure
Partition Manager(SPM) and NonSecure Hypervisor(NS_HYP). Extend/change
notify_type enumeration to accommodate all the 4 type and rejig the
values so that it can be reused in the bitmap enable mask macros.

While at this, move ffa_notify_type_get() so that it can be used in
notifier_hash_node_get() in the future.

No functional change.

Tested-by: Viresh Kumar <viresh.kumar@linaro.org>
Message-Id: <20250217-ffa_updates-v3-14-bd1d9de615e7@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
5 months agofirmware: arm_ffa: Remove unnecessary declaration of ffa_partitions_cleanup()
Sudeep Holla [Mon, 17 Feb 2025 15:38:54 +0000 (15:38 +0000)] 
firmware: arm_ffa: Remove unnecessary declaration of ffa_partitions_cleanup()

In order to keep the uniformity, just move the ffa_partitions_cleanup()
before it's first usage and drop the unnecessary forward declaration.

No functional change.

Tested-by: Viresh Kumar <viresh.kumar@linaro.org>
Message-Id: <20250217-ffa_updates-v3-13-bd1d9de615e7@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
5 months agofirmware: arm_ffa: Reject higher major version as incompatible
Sudeep Holla [Mon, 17 Feb 2025 15:38:53 +0000 (15:38 +0000)] 
firmware: arm_ffa: Reject higher major version as incompatible

When the firmware compatibility was handled previously in the commit
8e3f9da608f1 ("firmware: arm_ffa: Handle compatibility with different firmware versions"),
we only addressed firmware versions that have higher minor versions
compared to the driver version which is should be considered compatible
unless the firmware returns NOT_SUPPORTED.

However, if the firmware reports higher major version than the driver
supported, we need to reject it. If the firmware can work in a compatible
mode with the driver requested version, it must return the same major
version as requested.

Tested-by: Viresh Kumar <viresh.kumar@linaro.org>
Message-Id: <20250217-ffa_updates-v3-12-bd1d9de615e7@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
5 months agofirmware: arm_ffa: Upgrade FF-A version to v1.2 in the driver
Sudeep Holla [Mon, 17 Feb 2025 15:38:52 +0000 (15:38 +0000)] 
firmware: arm_ffa: Upgrade FF-A version to v1.2 in the driver

The basic and mandatory features of FF-A v1.2 are all supported now.
The driver supported version can be bumped from v1.1 to v1.2

Tested-by: Viresh Kumar <viresh.kumar@linaro.org>
Message-Id: <20250217-ffa_updates-v3-11-bd1d9de615e7@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
5 months agofirmware: arm_ffa: Add support for passing UUID in FFA_MSG_SEND2
Sudeep Holla [Mon, 17 Feb 2025 15:38:51 +0000 (15:38 +0000)] 
firmware: arm_ffa: Add support for passing UUID in FFA_MSG_SEND2

FF-A v1.2 introduces UUID field in partition message header used in
FFA_MSG_SEND2 to enable partitions/endpoints exposing multiple UUIDs.

Add the support for passing UUID in FFA_MSG_SEND2.

Tested-by: Viresh Kumar <viresh.kumar@linaro.org>
Message-Id: <20250217-ffa_updates-v3-10-bd1d9de615e7@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
5 months agofirmware: arm_ffa: Helper to check if a partition can receive REQUEST2 messages
Sudeep Holla [Mon, 17 Feb 2025 15:38:50 +0000 (15:38 +0000)] 
firmware: arm_ffa: Helper to check if a partition can receive REQUEST2 messages

Add a helper that allows FF-A drivers to check if the partition can
receive the direct requests via the FFA_MSG_SEND_DIRECT_REQ2 ABI.

Tested-by: Viresh Kumar <viresh.kumar@linaro.org>
Message-Id: <20250217-ffa_updates-v3-9-bd1d9de615e7@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
5 months agofirmware: arm_ffa: Unregister the FF-A devices when cleaning up the partitions
Sudeep Holla [Mon, 17 Feb 2025 15:38:49 +0000 (15:38 +0000)] 
firmware: arm_ffa: Unregister the FF-A devices when cleaning up the partitions

Both the FF-A core and the bus were in a single module before the
commit 18c250bd7ed0 ("firmware: arm_ffa: Split bus and driver into distinct modules").

The arm_ffa_bus_exit() takes care of unregistering all the FF-A devices.
Now that there are 2 distinct modules, if the core driver is unloaded and
reloaded, it will end up adding duplicate FF-A devices as the previously
registered devices weren't unregistered when we cleaned up the modules.

Fix the same by unregistering all the FF-A devices on the FF-A bus during
the cleaning up of the partitions and hence the cleanup of the module.

Fixes: 18c250bd7ed0 ("firmware: arm_ffa: Split bus and driver into distinct modules")
Tested-by: Viresh Kumar <viresh.kumar@linaro.org>
Message-Id: <20250217-ffa_updates-v3-8-bd1d9de615e7@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
5 months agofirmware: arm_ffa: Handle the presence of host partition in the partition info
Sudeep Holla [Mon, 17 Feb 2025 15:38:48 +0000 (15:38 +0000)] 
firmware: arm_ffa: Handle the presence of host partition in the partition info

Currently it is assumed that the firmware doesn't present the host
partition in the list of partitions presented as part of the response
to PARTITION_INFO_GET from the firmware. However, there are few
platforms that prefer to present the same in the list of partitions.
It is not manadatory but not restricted as well.

So handle the same by making sure to check the presence of the host
VM ID in the XArray partition information maintained/managed in the
driver before attempting to add it.

Tested-by: Viresh Kumar <viresh.kumar@linaro.org>
Message-Id: <20250217-ffa_updates-v3-7-bd1d9de615e7@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
5 months agofirmware: arm_ffa: Refactor addition of partition information into XArray
Viresh Kumar [Mon, 17 Feb 2025 15:38:47 +0000 (15:38 +0000)] 
firmware: arm_ffa: Refactor addition of partition information into XArray

Move the common code handling addition of the FF-A partition information
into the XArray as a new routine. No functional change.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Message-Id: <20250217-ffa_updates-v3-6-bd1d9de615e7@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
5 months agofirmware: arm_ffa: Fix big-endian support in __ffa_partition_info_regs_get()
Sudeep Holla [Mon, 17 Feb 2025 15:38:46 +0000 (15:38 +0000)] 
firmware: arm_ffa: Fix big-endian support in __ffa_partition_info_regs_get()

Currently the FF-A driver doesn't support big-endian correctly. It is
hard to regularly test the setup due to lack of test infrastructure and
tools.

In order to support full stack, we need to take small steps in getting
the support for big-endian kernel added slowly. This change fixes the
support in __ffa_partition_info_regs_get() so that the response from the
firmware are converted correctly as required. With this change, we can
enumerate all the FF-A devices correctly in the big-endian kernel if the
FFA_PARTITION_INFO_REGS_GET is supported.

Tested-by: Viresh Kumar <viresh.kumar@linaro.org>
Message-Id: <20250217-ffa_updates-v3-5-bd1d9de615e7@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
5 months agofirmware: arm_ffa: Fix big-endian support in __ffa_partition_info_get()
Sudeep Holla [Mon, 17 Feb 2025 15:38:45 +0000 (15:38 +0000)] 
firmware: arm_ffa: Fix big-endian support in __ffa_partition_info_get()

Currently the FF-A driver doesn't support big-endian correctly. It is
hard to regularly test the setup due to lack of test infrastructure and
tools.

In order to support full stack, we need to take small steps in getting
the support for big-endian kernel added slowly. This change fixes the
support in __ffa_partition_info_get() so that the response from the
firmware are converted correctly as required. With this change, we can
enumerate all the FF-A devices correctly in the big-endian kernel.

Tested-by: Viresh Kumar <viresh.kumar@linaro.org>
Message-Id: <20250217-ffa_updates-v3-4-bd1d9de615e7@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
5 months agofirmware: arm_ffa: Align sync_send_receive{,2} function prototypes
Sudeep Holla [Mon, 17 Feb 2025 15:38:44 +0000 (15:38 +0000)] 
firmware: arm_ffa: Align sync_send_receive{,2} function prototypes

Currently ffa_sync_send_receive2() takes UUID as a separate parameter
instead of using the one available in ffa_device structure.

Change the prototype of ffa_sync_send_receive2() to align with the
ffa_sync_send_receive() and use ffa_device->uuid.

Tested-by: Viresh Kumar <viresh.kumar@linaro.org>
Message-Id: <20250217-ffa_updates-v3-3-bd1d9de615e7@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
5 months agofirmware: arm_ffa: Replace UUID buffer to standard UUID format
Sudeep Holla [Mon, 17 Feb 2025 15:38:43 +0000 (15:38 +0000)] 
firmware: arm_ffa: Replace UUID buffer to standard UUID format

Currently ffa_partition_info structure holds the UUID in the format
compatible with the firmware interface. However, most of the functions
in the FF-A core driver deals directly with uuid_t type.

Replace UUID buffer to standard UUID format in the ffa_partition_info
structure.

Tested-by: Viresh Kumar <viresh.kumar@linaro.org>
Message-Id: <20250217-ffa_updates-v3-2-bd1d9de615e7@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
5 months agofirmware: arm_ffa: Replace SCMI by FF-A in the macro
Sudeep Holla [Mon, 17 Feb 2025 15:38:42 +0000 (15:38 +0000)] 
firmware: arm_ffa: Replace SCMI by FF-A in the macro

Commit 22779149e93d ("firmware: arm_ffa: Emit modalias for FF-A devices")
added modalias for FF-A devices. However the macro added used SCMI
incorrectly. Replace the reference to SCMI by FF-A and update the macro.
(i.e. s/SCMI/FFA/)

No functional change.

Tested-by: Viresh Kumar <viresh.kumar@linaro.org>
Message-Id: <20250217-ffa_updates-v3-1-bd1d9de615e7@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
5 months agofirmware: Exynos ACPM: Fix spelling mistake "Faile" -> "Failed"
Colin Ian King [Mon, 17 Feb 2025 09:13:41 +0000 (09:13 +0000)] 
firmware: Exynos ACPM: Fix spelling mistake "Faile" -> "Failed"

There is a spelling mistake in a dev_err_probe message. Fix it.

Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Link: https://lore.kernel.org/r/20250217091341.297401-1-colin.i.king@gmail.com
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
5 months agoLinux 6.14-rc3 v6.14-rc3
Linus Torvalds [Sun, 16 Feb 2025 22:02:44 +0000 (14:02 -0800)] 
Linux 6.14-rc3

5 months agoMerge tag 'kbuild-fixes-v6.14-2' of git://git.kernel.org/pub/scm/linux/kernel/git...
Linus Torvalds [Sun, 16 Feb 2025 20:58:51 +0000 (12:58 -0800)] 
Merge tag 'kbuild-fixes-v6.14-2' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild

Pull Kbuild fixes from Masahiro Yamada:

 - Fix annoying logs when building tools in parallel

 - Fix the Debian linux-headers package build again

 - Fix the target triple detection for userspace programs on Clang

* tag 'kbuild-fixes-v6.14-2' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild:
  modpost: Fix a few typos in a comment
  kbuild: userprogs: fix bitsize and target detection on clang
  kbuild: fix linux-headers package build when $(CC) cannot link userspace
  tools: fix annoying "mkdir -p ..." logs when building tools in parallel

5 months agoMerge tag 'driver-core-6.14-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git...
Linus Torvalds [Sun, 16 Feb 2025 20:54:42 +0000 (12:54 -0800)] 
Merge tag 'driver-core-6.14-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core

Pull driver core api addition from Greg KH:
 "Here is a driver core new api for 6.14-rc3 that is being added to
  allow platform devices from stop being abused.

  It adds a new 'faux_device' structure and bus and api to allow almost
  a straight or simpler conversion from platform devices that were not
  really a platform device. It also comes with a binding for rust, with
  an example driver in rust showing how it's used.

  I'm adding this now so that the patches that convert the different
  drivers and subsystems can all start flowing into linux-next now
  through their different development trees, in time for 6.15-rc1.

  We have a number that are already reviewed and tested, but adding
  those conversions now doesn't seem right. For now, no one is using
  this, and it passes all build tests from 0-day and linux-next, so all
  should be good"

* tag 'driver-core-6.14-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core:
  rust/kernel: Add faux device bindings
  driver core: add a faux bus for use when a simple device/bus is needed

5 months agoMerge tag 'tty-6.14-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty
Linus Torvalds [Sun, 16 Feb 2025 20:50:44 +0000 (12:50 -0800)] 
Merge tag 'tty-6.14-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty

Pull serial driver fixes from Greg KH:
 "Here are some small serial driver fixes for some reported problems.
  Nothing major, just:

   - sc16is7xx irq check fix

   - 8250 fifo underflow fix

   - serial_port and 8250 iotype fixes

  Most of these have been in linux-next already, and all have passed
  0-day testing"

* tag 'tty-6.14-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty:
  serial: 8250: Fix fifo underflow on flush
  serial: 8250_pnp: Remove unneeded ->iotype assignment
  serial: 8250_platform: Remove unneeded ->iotype assignment
  serial: 8250_of: Remove unneeded ->iotype assignment
  serial: port: Make ->iotype validation global in __uart_read_properties()
  serial: port: Always update ->iotype in __uart_read_properties()
  serial: port: Assign ->iotype correctly when ->iobase is set
  serial: sc16is7xx: Fix IRQ number check behavior

5 months agoMerge tag 'usb-6.14-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
Linus Torvalds [Sun, 16 Feb 2025 19:15:50 +0000 (11:15 -0800)] 
Merge tag 'usb-6.14-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb

Pull USB fixes from Greg KH:
 "Here are some small USB driver fixes, and new device ids, for
  6.14-rc3. Lots of tiny stuff for reported problems, including:

   - new device ids and quirks

   - usb hub crash fix found by syzbot

   - dwc2 driver fix

   - dwc3 driver fixes

   - uvc gadget driver fix

   - cdc-acm driver fixes for a variety of different issues

   - other tiny bugfixes

  Almost all of these have been in linux-next this week, and all have
  passed 0-day testing"

* tag 'usb-6.14-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (25 commits)
  usb: typec: tcpm: PSSourceOffTimer timeout in PR_Swap enters ERROR_RECOVERY
  usb: roles: set switch registered flag early on
  usb: gadget: uvc: Fix unstarted kthread worker
  USB: quirks: add USB_QUIRK_NO_LPM quirk for Teclast dist
  usb: gadget: core: flush gadget workqueue after device removal
  USB: gadget: f_midi: f_midi_complete to call queue_work
  usb: core: fix pipe creation for get_bMaxPacketSize0
  usb: dwc3: Fix timeout issue during controller enter/exit from halt state
  USB: Add USB_QUIRK_NO_LPM quirk for sony xperia xz1 smartphone
  USB: cdc-acm: Fill in Renesas R-Car D3 USB Download mode quirk
  usb: cdc-acm: Fix handling of oversized fragments
  usb: cdc-acm: Check control transfer buffer size before access
  usb: xhci: Restore xhci_pci support for Renesas HCs
  USB: pci-quirks: Fix HCCPARAMS register error for LS7A EHCI
  USB: serial: option: drop MeiG Smart defines
  USB: serial: option: fix Telit Cinterion FN990A name
  USB: serial: option: add Telit Cinterion FN990B compositions
  USB: serial: option: add MeiG Smart SLM828
  usb: gadget: f_midi: fix MIDI Streaming descriptor lengths
  usb: dwc2: gadget: remove of_node reference upon udc_stop
  ...

5 months agoMerge tag 'irq_urgent_for_v6.14_rc3' of git://git.kernel.org/pub/scm/linux/kernel...
Linus Torvalds [Sun, 16 Feb 2025 18:55:17 +0000 (10:55 -0800)] 
Merge tag 'irq_urgent_for_v6.14_rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

Pull irq Kconfig cleanup from Borislav Petkov:

 - Remove an unused config item GENERIC_PENDING_IRQ_CHIPFLAGS

* tag 'irq_urgent_for_v6.14_rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  genirq: Remove unused CONFIG_GENERIC_PENDING_IRQ_CHIPFLAGS

5 months agoMerge tag 'perf_urgent_for_v6.14_rc3' of git://git.kernel.org/pub/scm/linux/kernel...
Linus Torvalds [Sun, 16 Feb 2025 18:41:50 +0000 (10:41 -0800)] 
Merge tag 'perf_urgent_for_v6.14_rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

Pull x86 perf fixes from Borislav Petkov:

 - Explicitly clear DEBUGCTL.LBR to prevent LBRs continuing being
   enabled after handoff to the OS

 - Check CPUID(0x23) leaf and subleafs presence properly

 - Remove the PEBS-via-PT feature from being supported on hybrid systems

 - Fix perf record/top default commands on systems without a raw PMU
   registered

* tag 'perf_urgent_for_v6.14_rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  perf/x86/intel: Ensure LBRs are disabled when a CPU is starting
  perf/x86/intel: Fix ARCH_PERFMON_NUM_COUNTER_LEAF
  perf/x86/intel: Clean up PEBS-via-PT on hybrid
  perf/x86/rapl: Fix the error checking order

5 months agoMerge tag 'sched_urgent_for_v6.14_rc3' of git://git.kernel.org/pub/scm/linux/kernel...
Linus Torvalds [Sun, 16 Feb 2025 18:38:24 +0000 (10:38 -0800)] 
Merge tag 'sched_urgent_for_v6.14_rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

Pull scheduler fix from Borislav Petkov:

 - Clarify what happens when a task is woken up from the wake queue and
   make clear its removal from that queue is atomic

* tag 'sched_urgent_for_v6.14_rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  sched: Clarify wake_up_q()'s write to task->wake_q.next

5 months agoMerge tag 'objtool_urgent_for_v6.14_rc3' of git://git.kernel.org/pub/scm/linux/kernel...
Linus Torvalds [Sun, 16 Feb 2025 18:30:58 +0000 (10:30 -0800)] 
Merge tag 'objtool_urgent_for_v6.14_rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

Pull objtool fixes from Borislav Petkov:

 - Move a warning about a lld.ld breakage into the verbose setting as
   said breakage has been fixed in the meantime

 - Teach objtool to ignore dangling jump table entries added by Clang

* tag 'objtool_urgent_for_v6.14_rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  objtool: Move dodgy linker warn to verbose
  objtool: Ignore dangling jump table entries

5 months agoMerge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm
Linus Torvalds [Sun, 16 Feb 2025 18:25:12 +0000 (10:25 -0800)] 
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm

Pull kvm fixes from Paolo Bonzini:
 "ARM:

   - Large set of fixes for vector handling, especially in the
     interactions between host and guest state.

     This fixes a number of bugs affecting actual deployments, and
     greatly simplifies the FP/SIMD/SVE handling. Thanks to Mark Rutland
     for dealing with this thankless task.

   - Fix an ugly race between vcpu and vgic creation/init, resulting in
     unexpected behaviours

   - Fix use of kernel VAs at EL2 when emulating timers with nVHE

   - Small set of pKVM improvements and cleanups

  x86:

   - Fix broken SNP support with KVM module built-in, ensuring the PSP
     module is initialized before KVM even when the module
     infrastructure cannot be used to order initcalls

   - Reject Hyper-V SEND_IPI hypercalls if the local APIC isn't being
     emulated by KVM to fix a NULL pointer dereference

   - Enter guest mode (L2) from KVM's perspective before initializing
     the vCPU's nested NPT MMU so that the MMU is properly tagged for
     L2, not L1

   - Load the guest's DR6 outside of the innermost .vcpu_run() loop, as
     the guest's value may be stale if a VM-Exit is handled in the
     fastpath"

* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: (25 commits)
  x86/sev: Fix broken SNP support with KVM module built-in
  KVM: SVM: Ensure PSP module is initialized if KVM module is built-in
  crypto: ccp: Add external API interface for PSP module initialization
  KVM: arm64: vgic: Hoist SGI/PPI alloc from vgic_init() to kvm_create_vgic()
  KVM: arm64: timer: Drop warning on failed interrupt signalling
  KVM: arm64: Fix alignment of kvm_hyp_memcache allocations
  KVM: arm64: Convert timer offset VA when accessed in HYP code
  KVM: arm64: Simplify warning in kvm_arch_vcpu_load_fp()
  KVM: arm64: Eagerly switch ZCR_EL{1,2}
  KVM: arm64: Mark some header functions as inline
  KVM: arm64: Refactor exit handlers
  KVM: arm64: Refactor CPTR trap deactivation
  KVM: arm64: Remove VHE host restore of CPACR_EL1.SMEN
  KVM: arm64: Remove VHE host restore of CPACR_EL1.ZEN
  KVM: arm64: Remove host FPSIMD saving for non-protected KVM
  KVM: arm64: Unconditionally save+flush host FPSIMD/SVE/SME state
  KVM: x86: Load DR6 with guest value only before entering .vcpu_run() loop
  KVM: nSVM: Enter guest mode before initializing nested NPT MMU
  KVM: selftests: Add CPUID tests for Hyper-V features that need in-kernel APIC
  KVM: selftests: Manage CPUID array in Hyper-V CPUID test's core helper
  ...

5 months agoMerge tag 'mips-fixes_6.14_1' of git://git.kernel.org/pub/scm/linux/kernel/git/mips...
Linus Torvalds [Sun, 16 Feb 2025 18:19:41 +0000 (10:19 -0800)] 
Merge tag 'mips-fixes_6.14_1' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux

Pull MIPS fixes from Thomas Bogendoerfer:
 "Fix for o32 ptrace/get_syscall_info"

* tag 'mips-fixes_6.14_1' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux:
  MIPS: fix mips_get_syscall_arg() for o32
  MIPS: Export syscall stack arguments properly for remote use

5 months agoMAINTAINERS: add entry for the Samsung Exynos ACPM mailbox protocol
Tudor Ambarus [Thu, 13 Feb 2025 13:05:16 +0000 (13:05 +0000)] 
MAINTAINERS: add entry for the Samsung Exynos ACPM mailbox protocol

Add entry for the Samsung Exynos ACPM mailbox protocol.

Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Link: https://lore.kernel.org/r/20250213-gs101-acpm-v9-3-8b0281b93c8b@linaro.org
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
5 months agofirmware: add Exynos ACPM protocol driver
Tudor Ambarus [Thu, 13 Feb 2025 13:05:15 +0000 (13:05 +0000)] 
firmware: add Exynos ACPM protocol driver

Alive Clock and Power Manager (ACPM) Message Protocol is defined for
the purpose of communication between the ACPM firmware and masters
(AP, AOC, ...). ACPM firmware operates on the Active Power Management
(APM) module that handles overall power activities.

ACPM and masters regard each other as independent hardware component and
communicate with each other using mailbox messages and shared memory.

This protocol driver provides the interface for all the client drivers
making use of the features offered by the APM. Add ACPM protocol support.

Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Link: https://lore.kernel.org/r/20250213-gs101-acpm-v9-2-8b0281b93c8b@linaro.org
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
5 months agodt-bindings: firmware: add google,gs101-acpm-ipc
Tudor Ambarus [Thu, 13 Feb 2025 13:05:14 +0000 (13:05 +0000)] 
dt-bindings: firmware: add google,gs101-acpm-ipc

Add bindings for the Samsung Exynos ACPM mailbox protocol.

Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20250213-gs101-acpm-v9-1-8b0281b93c8b@linaro.org
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
5 months agoMerge tag 'devicetree-fixes-for-6.14-1' of git://git.kernel.org/pub/scm/linux/kernel...
Linus Torvalds [Sun, 16 Feb 2025 01:20:39 +0000 (17:20 -0800)] 
Merge tag 'devicetree-fixes-for-6.14-1' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux

Pull devicetree fixes from Rob Herring:

 - Add bindings for QCom QCS8300 clocks, QCom SAR2130P qfprom, and
   powertip,{st7272|hx8238a} displays

 - Fix compatible for TI am62a7 dss

 - Add a kunit test for __of_address_resource_bounds()

* tag 'devicetree-fixes-for-6.14-1' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux:
  dt-bindings: display: Add powertip,{st7272|hx8238a} as DT Schema description
  dt-bindings: nvmem: qcom,qfprom: Add SAR2130P compatible
  dt-bindings: display: ti: Fix compatible for am62a7 dss
  of: address: Add kunit test for __of_address_resource_bounds()
  dt-bindings: clock: qcom: Add QCS8300 video clock controller
  dt-bindings: clock: qcom: Add CAMCC clocks for QCS8300
  dt-bindings: clock: qcom: Add GPU clocks for QCS8300

5 months agoMerge tag 'uml-for-linus-6.14-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git...
Linus Torvalds [Sun, 16 Feb 2025 01:14:53 +0000 (17:14 -0800)] 
Merge tag 'uml-for-linus-6.14-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/uml/linux

Pull UML fixes from Richard Weinberger:

 - Align signal stack correctly

 - Convert to raw spinlocks where needed (irq and virtio)

 - FPU related fixes

* tag 'uml-for-linus-6.14-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/uml/linux:
  um: convert irq_lock to raw spinlock
  um: virtio_uml: use raw spinlock
  um: virt-pci: don't use kmalloc()
  um: fix execve stub execution on old host OSs
  um: properly align signal stack on x86_64
  um: avoid copying FP state from init_task
  um: add back support for FXSAVE registers

5 months agoMerge tag 'trace-ring-buffer-v6.14-rc2' of git://git.kernel.org/pub/scm/linux/kernel...
Linus Torvalds [Sun, 16 Feb 2025 00:34:41 +0000 (16:34 -0800)] 
Merge tag 'trace-ring-buffer-v6.14-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace

Pull trace ring buffer fixes from Steven Rostedt:

 - Enable resize on mmap() error

   When a process mmaps a ring buffer, its size is locked and resizing
   is disabled. But if the user passes in a wrong parameter, the mmap()
   can fail after the resize was disabled and the mmap() exits with
   error without reenabling the ring buffer resize. This prevents the
   ring buffer from ever being resized after that. Reenable resizing of
   the ring buffer on mmap() error.

 - Have resizing return proper error and not always -ENOMEM

   If the ring buffer is mmapped by one task and another task tries to
   resize the buffer it will error with -ENOMEM. This is confusing to
   the user as there may be plenty of memory available. Have it return
   the error that actually happens (in this case -EBUSY) where the user
   can understand why the resize failed.

 - Test the sub-buffer array to validate persistent memory buffer

   On boot up, the initialization of the persistent memory buffer will
   do a validation check to see if the content of the data is valid, and
   if so, it will use the memory as is, otherwise it re-initializes it.
   There's meta data in this persistent memory that keeps track of which
   sub-buffer is the reader page and an array that states the order of
   the sub-buffers. The values in this array are indexes into the
   sub-buffers. The validator checks to make sure that all the entries
   in the array are within the sub-buffer list index, but it does not
   check for duplications.

   While working on this code, the array got corrupted and had
   duplicates, where not all the sub-buffers were accounted for. This
   passed the validator as all entries were valid, but the link list was
   incorrect and could have caused a crash. The corruption only produced
   incorrect data, but it could have been more severe. To fix this,
   create a bitmask that covers all the sub-buffer indexes and set it to
   all zeros. While iterating the array checking the values of the array
   content, have it set a bit corresponding to the index in the array.
   If the bit was already set, then it is a duplicate and mark the
   buffer as invalid and reset it.

 - Prevent mmap()ing persistent ring buffer

   The persistent ring buffer uses vmap() to map the persistent memory.
   Currently, the mmap() logic only uses virt_to_page() to get the page
   from the ring buffer memory and use that to map to user space. This
   works because a normal ring buffer uses alloc_page() to allocate its
   memory. But because the persistent ring buffer use vmap() it causes a
   kernel crash.

   Fixing this to work with vmap() is not hard, but since mmap() on
   persistent memory buffers never worked, just have the mmap() return
   -ENODEV (what was returned before mmap() for persistent memory ring
   buffers, as they never supported mmap. Normal buffers will still
   allow mmap(). Implementing mmap() for persistent memory ring buffers
   can wait till the next merge window.

 - Fix polling on persistent ring buffers

   There's a "buffer_percent" option (default set to 50), that is used
   to have reads of the ring buffer binary data block until the buffer
   fills to that percentage. The field "pages_touched" is incremented
   every time a new sub-buffer has content added to it. This field is
   used in the calculations to determine the amount of content is in the
   buffer and if it exceeds the "buffer_percent" then it will wake the
   task polling on the buffer.

   As persistent ring buffers can be created by the content from a
   previous boot, the "pages_touched" field was not updated. This means
   that if a task were to poll on the persistent buffer, it would block
   even if the buffer was completely full. It would block even if the
   "buffer_percent" was zero, because with "pages_touched" as zero, it
   would be calculated as the buffer having no content. Update
   pages_touched when initializing the persistent ring buffer from a
   previous boot.

* tag 'trace-ring-buffer-v6.14-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace:
  ring-buffer: Update pages_touched to reflect persistent buffer content
  tracing: Do not allow mmap() of persistent ring buffer
  ring-buffer: Validate the persistent meta data subbuf array
  tracing: Have the error of __tracing_resize_ring_buffer() passed to user
  ring-buffer: Unlock resize on mmap error

5 months agoring-buffer: Update pages_touched to reflect persistent buffer content
Steven Rostedt [Fri, 14 Feb 2025 17:35:12 +0000 (12:35 -0500)] 
ring-buffer: Update pages_touched to reflect persistent buffer content

The pages_touched field represents the number of subbuffers in the ring
buffer that have content that can be read. This is used in accounting of
"dirty_pages" and "buffer_percent" to allow the user to wait for the
buffer to be filled to a certain amount before it reads the buffer in
blocking mode.

The persistent buffer never updated this value so it was set to zero, and
this accounting would take it as it had no content. This would cause user
space to wait for content even though there's enough content in the ring
buffer that satisfies the buffer_percent.

Cc: stable@vger.kernel.org
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Vincent Donnefort <vdonnefort@google.com>
Link: https://lore.kernel.org/20250214123512.0631436e@gandalf.local.home
Fixes: 5f3b6e839f3ce ("ring-buffer: Validate boot range memory events")
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
5 months agotracing: Do not allow mmap() of persistent ring buffer
Steven Rostedt [Fri, 14 Feb 2025 16:55:47 +0000 (11:55 -0500)] 
tracing: Do not allow mmap() of persistent ring buffer

When trying to mmap a trace instance buffer that is attached to
reserve_mem, it would crash:

 BUG: unable to handle page fault for address: ffffe97bd00025c8
 #PF: supervisor read access in kernel mode
 #PF: error_code(0x0000) - not-present page
 PGD 2862f3067 P4D 2862f3067 PUD 0
 Oops: Oops: 0000 [#1] PREEMPT_RT SMP PTI
 CPU: 4 UID: 0 PID: 981 Comm: mmap-rb Not tainted 6.14.0-rc2-test-00003-g7f1a5e3fbf9e-dirty #233
 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
 RIP: 0010:validate_page_before_insert+0x5/0xb0
 Code: e2 01 89 d0 c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 <48> 8b 46 08 a8 01 75 67 66 90 48 89 f0 8b 50 34 85 d2 74 76 48 89
 RSP: 0018:ffffb148c2f3f968 EFLAGS: 00010246
 RAX: ffff9fa5d3322000 RBX: ffff9fa5ccff9c08 RCX: 00000000b879ed29
 RDX: ffffe97bd00025c0 RSI: ffffe97bd00025c0 RDI: ffff9fa5ccff9c08
 RBP: ffffb148c2f3f9f0 R08: 0000000000000004 R09: 0000000000000004
 R10: 0000000000000000 R11: 0000000000000200 R12: 0000000000000000
 R13: 00007f16a18d5000 R14: ffff9fa5c48db6a8 R15: 0000000000000000
 FS:  00007f16a1b54740(0000) GS:ffff9fa73df00000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: ffffe97bd00025c8 CR3: 00000001048c6006 CR4: 0000000000172ef0
 Call Trace:
  <TASK>
  ? __die_body.cold+0x19/0x1f
  ? __die+0x2e/0x40
  ? page_fault_oops+0x157/0x2b0
  ? search_module_extables+0x53/0x80
  ? validate_page_before_insert+0x5/0xb0
  ? kernelmode_fixup_or_oops.isra.0+0x5f/0x70
  ? __bad_area_nosemaphore+0x16e/0x1b0
  ? bad_area_nosemaphore+0x16/0x20
  ? do_kern_addr_fault+0x77/0x90
  ? exc_page_fault+0x22b/0x230
  ? asm_exc_page_fault+0x2b/0x30
  ? validate_page_before_insert+0x5/0xb0
  ? vm_insert_pages+0x151/0x400
  __rb_map_vma+0x21f/0x3f0
  ring_buffer_map+0x21b/0x2f0
  tracing_buffers_mmap+0x70/0xd0
  __mmap_region+0x6f0/0xbd0
  mmap_region+0x7f/0x130
  do_mmap+0x475/0x610
  vm_mmap_pgoff+0xf2/0x1d0
  ksys_mmap_pgoff+0x166/0x200
  __x64_sys_mmap+0x37/0x50
  x64_sys_call+0x1670/0x1d70
  do_syscall_64+0xbb/0x1d0
  entry_SYSCALL_64_after_hwframe+0x77/0x7f

The reason was that the code that maps the ring buffer pages to user space
has:

page = virt_to_page((void *)cpu_buffer->subbuf_ids[s]);

And uses that in:

vm_insert_pages(vma, vma->vm_start, pages, &nr_pages);

But virt_to_page() does not work with vmap()'d memory which is what the
persistent ring buffer has. It is rather trivial to allow this, but for
now just disable mmap() of instances that have their ring buffer from the
reserve_mem option.

If an mmap() is performed on a persistent buffer it will return -ENODEV
just like it would if the .mmap field wasn't defined in the
file_operations structure.

Cc: stable@vger.kernel.org
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Vincent Donnefort <vdonnefort@google.com>
Link: https://lore.kernel.org/20250214115547.0d7287d3@gandalf.local.home
Fixes: 9b7bdf6f6ece6 ("tracing: Have trace_printk not use binary prints if boot buffer")
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
5 months agoMerge tag 'i2c-for-6.14-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa...
Linus Torvalds [Sat, 15 Feb 2025 18:20:47 +0000 (10:20 -0800)] 
Merge tag 'i2c-for-6.14-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux

Pull i2c fixes from Wolfram Sang:
 "MAINTAINERS maintenance.

  Changed email, added entry, deleted entry falling back to a generic
  one"

* tag 'i2c-for-6.14-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux:
  MAINTAINERS: Add maintainer for Qualcomm's I2C GENI driver
  MAINTAINERS: delete entry for AXXIA I2C
  MAINTAINERS: Use my kernel.org address for I2C ACPI work

5 months agoMerge tag 's390-6.14-4' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux
Linus Torvalds [Sat, 15 Feb 2025 18:15:24 +0000 (10:15 -0800)] 
Merge tag 's390-6.14-4' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux

Pull s390 fixes from Vasily Gorbik:

 - Fix isolated VFs handling by verifying that a VF’s parent PF is
   locally owned before registering it in an existing PCI domain

 - Disable arch_test_bit() optimization for PROFILE_ALL_BRANCHES to
   workaround gcc failure in handling __builtin_constant_p() in this
   case

 - Fix CHPID "configure" attribute caching in CIO by not updating the
   cache when SCLP returns no data, ensuring consistent sysfs output

 - Remove CONFIG_LSM from default configs and rely on defaults, which
   enables BPF LSM hook

* tag 's390-6.14-4' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
  s390/pci: Fix handling of isolated VFs
  s390/pci: Pull search for parent PF out of zpci_iov_setup_virtfn()
  s390/bitops: Disable arch_test_bit() optimization for PROFILE_ALL_BRANCHES
  s390/cio: Fix CHPID "configure" attribute caching
  s390/configs: Remove CONFIG_LSM

5 months agomodpost: Fix a few typos in a comment
Uwe Kleine-König [Thu, 13 Feb 2025 16:04:29 +0000 (17:04 +0100)] 
modpost: Fix a few typos in a comment

Namely: s/becasue/because/ and s/wiht/with/ plus an added article.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
5 months agokbuild: userprogs: fix bitsize and target detection on clang
Thomas Weißschuh [Thu, 13 Feb 2025 14:55:17 +0000 (15:55 +0100)] 
kbuild: userprogs: fix bitsize and target detection on clang

scripts/Makefile.clang was changed in the linked commit to move --target from
KBUILD_CFLAGS to KBUILD_CPPFLAGS, as that generally has a broader scope.
However that variable is not inspected by the userprogs logic,
breaking cross compilation on clang.

Use both variables to detect bitsize and target arguments for userprogs.

Fixes: feb843a469fb ("kbuild: add $(CLANG_FLAGS) to KBUILD_CPPFLAGS")
Cc: stable@vger.kernel.org
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
5 months agoMerge tag 'rust-fixes-6.14-2' of git://git.kernel.org/pub/scm/linux/kernel/git/ojeda...
Linus Torvalds [Sat, 15 Feb 2025 17:54:46 +0000 (09:54 -0800)] 
Merge tag 'rust-fixes-6.14-2' of git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux

Pull rust fixes from Miguel Ojeda:

 - Fix objtool warning due to future Rust 1.85.0 (to be released in a
   few days)

 - Clean future Rust 1.86.0 (to be released 2025-04-03) Clippy warning

* tag 'rust-fixes-6.14-2' of git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux:
  rust: rbtree: fix overindented list item
  objtool/rust: add one more `noreturn` Rust function

5 months agotegra210-adma: fix 32-bit x86 build
Linus Torvalds [Sat, 15 Feb 2025 17:28:55 +0000 (09:28 -0800)] 
tegra210-adma: fix 32-bit x86 build

The Tegra210 Audio DMA controller driver did a plain divide:

page_no = (res_page->start - res_base->start) / cdata->ch_base_offset;

which causes problems on 32-bit x86 configurations that have 64-bit
resource sizes:

  x86_64-linux-ld: drivers/dma/tegra210-adma.o: in function `tegra_adma_probe':
  tegra210-adma.c:(.text+0x1322): undefined reference to `__udivdi3'

because gcc doesn't generate the trivial code for a 64-by-32 divide,
turning it into a function call to do a full 64-by-64 divide.  And the
kernel intentionally doesn't provide that helper function, because 99%
of the time all you want is the narrower version.

Of course, tegra210 is a 64-bit architecture and the 32-bit x86 build is
purely for build testing, so this really is just about build coverage
failure.

But build coverage is good.

Side note: div_u64() would be suboptimal if you actually have a 32-bit
resource_t, so our "helper" for divides are admittedly making it harder
than it should be to generate good code for all the possible cases.

At some point, I'll consider 32-bit x86 so entirely legacy that I can't
find it in myself to care any more, and we'll just add the __udivdi3
library function.

But for now, the right thing to do is to use "div_u64()" to show that
you know that you are doing the simpler divide with a 32-bit number.
And the build error enforces that.

While fixing the build issue, also check for division-by-zero, and for
overflow.  Which hopefully cannot happen on real production hardware,
but the value of 'ch_base_offset' can definitely be zero in other
places.

Reported-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
5 months agoMerge tag 'gpio-fixes-for-v6.14-rc3-take2' of git://git.kernel.org/pub/scm/linux...
Linus Torvalds [Sat, 15 Feb 2025 16:13:45 +0000 (08:13 -0800)] 
Merge tag 'gpio-fixes-for-v6.14-rc3-take2' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux

Pull gpio fixes from Bartosz Golaszewski:

 - fix interrupt handling issues in gpio-bcm-kona

 - add an ACPI quirk for Acer Nitro ANV14 fixing an issue with spurious
   wake up events

 - add missing return value checks to gpio-stmpe

 - fix a crash in error path in gpiochip_get_ngpios()

* tag 'gpio-fixes-for-v6.14-rc3-take2' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux:
  gpiolib: Fix crash on error in gpiochip_get_ngpios()
  gpio: stmpe: Check return value of stmpe_reg_read in stmpe_gpio_irq_sync_unlock
  gpiolib: acpi: Add a quirk for Acer Nitro ANV14
  gpio: bcm-kona: Add missing newline to dev_err format string
  gpio: bcm-kona: Make sure GPIO bits are unlocked when requesting IRQ
  gpio: bcm-kona: Fix GPIO lock/unlock for banks above bank 0

5 months agokbuild: fix linux-headers package build when $(CC) cannot link userspace
Masahiro Yamada [Thu, 13 Feb 2025 06:26:44 +0000 (15:26 +0900)] 
kbuild: fix linux-headers package build when $(CC) cannot link userspace

Since commit 5f73e7d0386d ("kbuild: refactor cross-compiling
linux-headers package"), the linux-headers Debian package fails to
build when $(CC) cannot build userspace applications, for example,
when using toolchains installed by the 0day bot.

The host programs in the linux-headers package should be rebuilt using
the disto's cross-compiler, ${DEB_HOST_GNU_TYPE}-gcc instead of $(CC).
Hence, the variable 'CC' must be expanded in this shell script instead
of in the top-level Makefile.

Commit f354fc88a72a ("kbuild: install-extmod-build: add missing
quotation marks for CC variable") was not a correct fix because
CC="ccache gcc" should be unrelated when rebuilding userspace tools.

Fixes: 5f73e7d0386d ("kbuild: refactor cross-compiling linux-headers package")
Reported-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
Closes: https://lore.kernel.org/linux-kbuild/CAK7LNARb3xO3ptBWOMpwKcyf3=zkfhMey5H2KnB1dOmUwM79dA@mail.gmail.com/T/#t
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Tested-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
5 months agosoc: samsung: exynos-chipid: Add NULL pointer check in exynos_chipid_probe()
Chenyuan Yang [Wed, 12 Feb 2025 21:35:18 +0000 (15:35 -0600)] 
soc: samsung: exynos-chipid: Add NULL pointer check in exynos_chipid_probe()

soc_dev_attr->revision could be NULL, thus,
a pointer check is added to prevent potential NULL pointer dereference.
This is similar to the fix in commit 3027e7b15b02
("ice: Fix some null pointer dereference issues in ice_ptp.c").

This issue is found by our static analysis tool.

Signed-off-by: Chenyuan Yang <chenyuan0y@gmail.com>
Link: https://lore.kernel.org/r/20250212213518.69432-1-chenyuan0y@gmail.com
Fixes: 3253b7b7cd44 ("soc: samsung: Add exynos chipid driver support")
Cc: <stable@vger.kernel.org>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>