Drop the debugfs implementation of the ECDSA message signing, in
preparation for a new implementation via the keyctl() syscall.
Signed-off-by: Marek Behún <kabel@kernel.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Add support for digital message signing with the private key stored in
the MCU. Turris Omnia boards with MKL MCUs have a NIST256p ECDSA private
key generated and burned into MCU's flash when manufactured. The private
key is not readable from the MCU, but MCU allows for signing messages
with it and retrieving the public key.
This is exposed to userspace via the keyctl API.
In userspace, the user can look at /proc/keys or list the keyring:
$ cat /proc/keys
0a3b7cd3 ... keyring .turris-signing-keys: 1
3caf0b1a ... turris-om Turris Omnia SN 0000000A1000023 MCU ECDSA k...
$ keyctl rlist %:.turris-signing-keys
1018104602
To get the public key:
$ keyctl read 1018104602
33 bytes of data in key:
025d9108 1fb538ae 8435c88b b4379171 d6b158a9 55751b91 1d23e6a9 d017f4b2
1c
To sign a message:
$ dd if=/dev/urandom of=msg_to_sign bs=32 count=1
$ keyctl pkey_sign 1018104602 0 msg_to_sign >signature
Signed-off-by: Marek Behún <kabel@kernel.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Some Turris devices support signing messages with a per-device unique
asymmetric key that was created on the device at manufacture time.
Add helper module that helps to expose this ability via the keyctl()
syscall.
A device-specific driver can register a signing key by calling
devm_turris_signing_key_create().
Both the `.turris-signing-keys` keyring and the signing key are created
with only the VIEW, READ and SEARCH permissions for userspace - it is
impossible to link / unlink / move them, set their attributes, or unlink
the keyring from userspace.
Signed-off-by: Marek Behún <kabel@kernel.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Refactor the code that gets and requests the TRNG MCU interrupt in the
TRNG part of the driver into a helper function and put it into the GPIO
part of the driver.
Signed-off-by: Marek Behún <kabel@kernel.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
More Qualcomm driver updates for v6.15
Introduce Devicetree binding for providing board-specific firmware-name
for the GENI serial engine block. Add SDM630/636 support in pd-mapper.
Clean up and fix error handling in the SSC block bus driver.
Add missing msm8916-acc compatible to resolve a number of Devicetree
validation errors.
* tag 'qcom-drivers-for-6.15-2' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux:
dt-bindings: power: qcom,kpss-acc-v2: add qcom,msm8916-acc compatible
bus: qcom-ssc-block-bus: Fix the error handling path of qcom_ssc_block_bus_probe()
bus: qcom-ssc-block-bus: Remove some duplicated iounmap() calls
soc: qcom: pd-mapper: Add support for SDM630/636
dt-bindings: qcom: geni-se: Add 'firmware-name' property for firmware loading
Link: https://lore.kernel.org/r/20250319142448.2279164-1-andersson@kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Qualcomm driver updates for v6.15
Improve the client interface for the Qualcomm ICE driver to avoid
leaking references, including fixing the client drivers to call the new
function.
Adopt str_on_off() helper in AOSS driver and mark non-global servreg QMI
element info array in the PDR driver static.
* tag 'qcom-drivers-for-6.15' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux:
soc: qcom: Do not expose internal servreg_location_entry_ei array
soc: qcom: ice: make of_qcom_ice_get() static
scsi: ufs: qcom: fix dev reference leaked through of_qcom_ice_get
mmc: sdhci-msm: fix dev reference leaked through of_qcom_ice_get
soc: qcom: ice: introduce devm_of_qcom_ice_get
dt-bindings: soc: qcom: qcom,pmic-glink: Document SM8750 compatible
soc: qcom: Use str_enable_disable-like helpers
Link: https://lore.kernel.org/r/20250317210158.2025380-1-andersson@kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
TI SoC driver updates for v6.15
- ti-sci: Default set to ARCH_K3 for the ti sci driver in preperation for
the driver to be default set as module in defconfig.
- k3-socinfo: Explicitly build up regmap instead of depending on syscon
helper
* tag 'ti-driver-soc-for-v6.15' of https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux:
firmware: config: ti-sci: Default set to ARCH_K3 for the ti sci driver
soc: ti: k3-socinfo: Do not use syscon helper to build regmap
Link: https://lore.kernel.org/r/20250312113826.ka63nijuftgs6h52@mocker
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
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>
The Amlogic A4 SoCs support 12 GPIO IRQ lines and 2 AO GPIO IRQ lines,
A5 SoCs support 12 GPIO IRQ lines, details are as below.
A4 IRQ Number:
- 72:55 18 pins on bank T
- 54:32 23 pins on bank X
- 31:16 16 pins on bank D
- 15:14 2 pins on bank E
- 13:0 14 pins on bank B
A4 AO IRQ Number:
- 7 1 pin on bank TESTN
- 6:0 7 pins on bank AO
A5 IRQ Number:
- 98 1 pin on bank TESTN
- 97:82 16 pins on bank Z
- 81:62 20 pins on bank X
- 61:48 14 pins on bank T
- 47:32 16 pins on bank D
- 31:27 5 pins on bank H
- 26:25 2 pins on bank E
- 24:14 11 pins on bank C
- 13:0 14 pins on bank B
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Xianwei Zhao <xianwei.zhao@amlogic.com>
Link: https://lore.kernel.org/r/20250311-irqchip-gpio-a4-a5-v5-2-ca4cc276c18c@amlogic.com
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
If qcom_ssc_block_bus_pds_enable() fails, the previous call to
qcom_ssc_block_bus_pds_attach() must be undone, as already done in the
remove function.
In order to do that, move the code related to the power domains management
to the end of the function, in order to avoid many changes in all the error
handling path that would need to go through the new error handling path.
Fixes: 97d485edc1 ("bus: add driver for initializing the SSC bus on (some) qcom SoCs")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/1b89ec7438c9a893c09083e8591772c8ad3cb599.1740932040.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
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>
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>
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>
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>
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: 6f9ea4dabd ("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>
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>
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>
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>
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>
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>
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: bc3fc5c051 ("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>
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: 060f7875bd ("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>
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>
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: c0349314d5 ("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>
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: da77c2d3d0 ("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>
