summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2024-03-04Merge tag 'scmi-updates-6.9' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into soc/drivers Arm SCMI updates for v6.9 Quite a few changes to extend support to SCMI v3.2 specification, to enhance notification handling and other miscellaneous updates. 1. Enhancements to notification handling Until now, trying to register a notifier for an unsuppported notification returned an error genrating unneeded message exchanges with the SCMI platform. This can be avoided by looking up in advance the specific protocol and resources available. With these changes SCMI driver user will fail to register a notifier if the related command or resource is not supported (like before) without the need of exchanging any message. Perf notifications are also extended to provide the pre-calculated frequencies corresponding to the level or index carried by the 2. More SCMI v3.2 related updates One of the main addition includes a centralized support to the SCMI core to handle v3.2 optional protocol version negotiation, so that at protocol initialization time, if the platform advertised version is newer than supported by the kernel and protocol version negotiation is supported, the SCMI core will attempt to negotiate an older protocol version. It also includes the clock get permissions which indicates if any of the clock operations are forbidden by the platform for the OSPM agent. It can be used in the clock driver to avoid unnecessary message exchanges between the kernel and the platform which will always end up with the failure. It also includes other missing bits of clock v3.2 protocol so that the supported protocol version can be bumped to 0x30000 (v3.2). 3. Miscellaneous updates This includes addition of warning if the domain frequency multiplier is 0 or rounded off to indicate the actual frequencies are either wrong ot rounded off, hardening of clock domain info lookups, addition of multiple protocols registration support within a SCMI driver, update to SCMI entry in MAINTAINERS to include HWMON driver and constifying the scmi_bus_type structure. This also includes couple for fixes to minor issues: double free in SMC transport cleanup path and struct kernel-doc warnings in optee transport. * tag 'scmi-updates-6.9' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux: (29 commits) MAINTAINERS: Update SCMI entry with HWMON driver firmware: arm_scmi: Update the supported clock protocol version firmware: arm_scmi: Add standard clock OEM definitions firmware: arm_scmi: Add clock check for extended config support firmware: arm_scmi: Add support for v3.2 NEGOTIATE_PROTOCOL_VERSION firmware: arm_scmi: Fix struct kernel-doc warnings in optee transport firmware: arm_scmi: Report frequencies in the perf notifications firmware: arm_scmi: Use opps_by_lvl to store opps firmware: arm_scmi: Implement is_notify_supported callback in powercap protocol firmware: arm_scmi: Implement is_notify_supported callback in reset protocol firmware: arm_scmi: Implement is_notify_supported callback in sensor protocol firmware: arm_scmi: Implement is_notify_supported callback in clock protocol firmware: arm_scmi: Implement is_notify_supported callback in system power protocol firmware: arm_scmi: Implement is_notify_supported callback in power protocol firmware: arm_scmi: Implement is_notify_supported callback in perf protocol firmware: arm_scmi: Add a common helper to check if a message is supported firmware: arm_scmi: Check for notification support firmware: arm_scmi: Make scmi_bus_type const firmware: arm_scmi: Fix double free in SMC transport cleanup path firmware: arm_scmi: Implement clock get permissions ... Link: https://lore.kernel.org/r/20240223033435.118028-1-sudeep.holla@arm.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-03-04Merge tag 'ffa-update-6.9' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into soc/drivers Arm FF-A update for v6.9 Another single and simple update to just constify the ffa_bus_type structure similar to other changes done treewide following the driver core changes to accomodate the same. * tag 'ffa-update-6.9' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux: firmware: arm_ffa: Make ffa_bus_type const Link: https://lore.kernel.org/r/20240223033250.117878-1-sudeep.holla@arm.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-02-23MAINTAINERS: Update SCMI entry with HWMON driverFlorian Fainelli
scmi-hwmon.c is tightly coupled with the SCMI subsystem, fold it under the SCMI subsystem MAINTAINERS umbrella. Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://lore.kernel.org/r/20240222193027.920006-1-florian.fainelli@broadcom.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-02-22firmware: arm_scmi: Update the supported clock protocol versionCristian Marussi
And finally update the supported clock protocol version to v3.2(0x30000). Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20240214183006.3403207-6-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-02-22firmware: arm_scmi: Add standard clock OEM definitionsCristian Marussi
Add a common enum to define the standard clock OEM types defined by the SCMI specification, so as to enable the configuration of such extended configuration properties with the existent clock protocol operations. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20240214183006.3403207-5-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-02-22firmware: arm_scmi: Add clock check for extended config supportCristian Marussi
SCMI v3.2 added support to set/get clock custom OEM types; such support is conditionally present, though, depending on an extended config attribute bit possibly advertised by the platform server on a per-domain base. Add a check to verify if OEM types are supported before allowing any kind of OEM-specific get/set operation. Also add a check around all the new v3.2 clock features. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20240214183006.3403207-4-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-02-22firmware: arm_scmi: Add support for v3.2 NEGOTIATE_PROTOCOL_VERSIONCristian Marussi
Freshly introduced NEGOTIATE_PROTOCOL_VERSION allows the agent to ascertain upfront if a specific protocol(usually older) version is supported by the platform. It is used by the agent in case the platform has advertised the support of a newer protocol version than the latest version supported by the agent, since backward compatibility cannot be automatically assumed. Emit a warning about possible incompatibility when negotiation was not possible or just print the successfully negotiated protocol. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20240214183006.3403207-3-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-02-22firmware: arm_scmi: Fix struct kernel-doc warnings in optee transportRandy Dunlap
Fix the kernel-doc notation for the nested union in struct scmi_optee_channel to eliminate kernel-doc warnings: | optee.c:130: warning: Excess struct member 'shmem' description | in 'scmi_optee_channel' | optee.c:131: warning: Function parameter or struct member 'req' | not described in 'scmi_optee_channel' Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Sudeep Holla <sudeep.holla@arm.com> Cc: Cristian Marussi <cristian.marussi@arm.com> Cc: <linux-arm-kernel@lists.infradead.org> Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20240221062157.8694-1-rdunlap@infradead.org Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-02-20Merge tag 'memory-controller-drv-6.9' of ↵Arnd Bergmann
https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-mem-ctrl into soc/drivers Memory controller drivers for v6.9 1. TI EMIF: Simplify handling CONFIG_DEBUG_FS, CONFIG_OF and platform_driver_probe(). 2. Narrow regex in Nvidia Tegra20 EMC binding. * tag 'memory-controller-drv-6.9' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-mem-ctrl: dt-bindings: memory-controllers: narrow regex for unit address to hex numbers memory: emif: Drop usage of platform_driver_probe() memory: emif: Simplify code handling CONFIG_OF memory: emif: Simplify code handling CONFIG_DEBUG_FS Link: https://lore.kernel.org/r/20240218183046.32721-1-krzysztof.kozlowski@linaro.org Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-02-20Merge tag 'samsung-drivers-6.9' of ↵Arnd Bergmann
https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux into soc/drivers Samsung SoC driver changes for v6.9 1. Add bindings for Google GS101 I2C controller and SYSREG sycon block. 2. Remove Tomasz Figa from Samsung clock and pinctrl maintainer entries. * tag 'samsung-drivers-6.9' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux: MAINTAINERS: Remove Tomasz from Samsung clock and pinctrl entries dt-bindings: samsung: exynos-sysreg: gs101-peric0/1 require a clock dt-bindings: i2c: exynos5: add google,gs101-hsi2c compatible Link: https://lore.kernel.org/r/20240218182141.31213-1-krzysztof.kozlowski@linaro.org Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-02-20Merge tag 'renesas-drivers-for-v6.9-tag1' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel into soc/drivers Renesas driver updates for v6.9 - Initial support for the Renesas R-Car V4M (R8A779H0) SoC. * tag 'renesas-drivers-for-v6.9-tag1' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel: soc: renesas: rcar-rst: Add support for R-Car V4M soc: renesas: Identify R-Car V4M soc: renesas: Introduce ARCH_RCAR_GEN4 Link: https://lore.kernel.org/r/cover.1707487830.git.geert+renesas@glider.be Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-02-20Merge tag 'mtk-soc-for-v6.9' of ↵Arnd Bergmann
https://git.kernel.org/pub/scm/linux/kernel/git/mediatek/linux into soc/drivers MediaTek soc driver updates for v6.9 The only addition here is the MediaTek SoC Information driver, registering socinfo for various MediaTek SoCs. * tag 'mtk-soc-for-v6.9' of https://git.kernel.org/pub/scm/linux/kernel/git/mediatek/linux: soc: mediatek: mtk-socinfo: Add extra entry for MT8183 soc: mediatek: mtk-socinfo: Clean up NVMEM cell read soc: mediatek: mtk-socinfo: Add driver for getting chip information Link: https://lore.kernel.org/r/20240219131230.157792-2-angelogioacchino.delregno@collabora.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-02-20firmware: arm_scmi: Report frequencies in the perf notificationsCristian Marussi
Extend the perf notification report to include pre-calculated frequencies corresponding to the reported limits/levels event; such frequencies are properly computed based on the stored known OPPs information taking into consideration if the current operating mode is level indexed or not. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20240212123233.1230090-12-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-02-20firmware: arm_scmi: Use opps_by_lvl to store oppsCristian Marussi
Store all the discovered OPPs into the XArray opps_by_lvl even when level_indexing mode is not used, since it comes handy to easily retrieve OPPs by level. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20240212123233.1230090-11-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-02-20firmware: arm_scmi: Implement is_notify_supported callback in powercap protocolCristian Marussi
Add a preliminary check to verify if the powercap protocol related notify enable commands are supported at all by the SCMI platform, and then provide the callback needed to allow the core SCMI notification subsytem to do a fine-grain check if a specific resource domain supports notifications. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20240212123233.1230090-10-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-02-20firmware: arm_scmi: Implement is_notify_supported callback in reset protocolCristian Marussi
Add a preliminary check to verify if the reset protocol related notify enable commands are supported at all by the SCMI platform, and then provide the callback needed to allow the core SCMI notification subsytem to do a fine-grain check if a specific resource domain supports notifications. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20240212123233.1230090-9-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-02-20firmware: arm_scmi: Implement is_notify_supported callback in sensor protocolCristian Marussi
Add a preliminary check to verify if the sensor protocol related notify enable commands are supported at all by the SCMI platform, and then provide the callback needed to allow the core SCMI notification subsytem to do a fine-grain check if a specific resource domain supports notifications. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20240212123233.1230090-8-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-02-20firmware: arm_scmi: Implement is_notify_supported callback in clock protocolCristian Marussi
Add a preliminary check to verify if the clock protocol related notify enable commands are supported at all by the SCMI platform, and then provide the callback needed to allow the core SCMI notification subsytem to do a fine-grain check if a specific resource domain supports notifications. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20240212123233.1230090-7-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-02-20firmware: arm_ffa: Make ffa_bus_type constRicardo B. Marliere
Now that the driver core can properly handle constant struct bus_type, move the ffa_bus_type variable to be a constant structure as well, placing it into read-only memory which can not be modified at runtime. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ricardo B. Marliere <ricardo@marliere.net> Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20240211-bus_cleanup-firmware2-v1-1-1851c92c7be7@marliere.net Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-02-20firmware: arm_scmi: Implement is_notify_supported callback in system power ↵Cristian Marussi
protocol Add a preliminary check to verify if the system power protocol related notify enable commands are supported at all by the SCMI platform, and then provide the callback needed to allow the core SCMI notification subsytem to do a fine-grain check if a specific resource domain supports notifications. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20240212123233.1230090-6-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-02-20firmware: arm_scmi: Implement is_notify_supported callback in power protocolCristian Marussi
Add a preliminary check to verify if the power related notify enable commands are supported at all by the SCMI platform, and then provide the callback needed to allow the core SCMI notification subsytem to do a fine-grain check if a specific resource domain supports notifications. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20240212123233.1230090-5-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-02-20firmware: arm_scmi: Implement is_notify_supported callback in perf protocolCristian Marussi
Add a preliminary check to verify if the performance related notify enable commands are supported at all by the SCMI platform, and then provide the callback needed to allow the core SCMI notification subsytem to do a fine-grain check if a specific resource domain supports notifications. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20240212123233.1230090-4-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-02-20firmware: arm_scmi: Add a common helper to check if a message is supportedCristian Marussi
A common helper is provided to check if a specific protocol message is supported or not. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20240212123233.1230090-3-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-02-20firmware: arm_scmi: Check for notification supportCristian Marussi
When registering protocol events, use the optional .is_notify_supported callback provided by the protocol to check if that specific notification type is available for that particular resource on the running system, marking it as unsupported otherwise. Then, when a notification enable request is received, return an error if it was previously marked as unsuppported, so avoiding to send a needless notification enable command and check the returned value for failure. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20240212123233.1230090-2-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-02-20firmware: arm_scmi: Make scmi_bus_type constRicardo B. Marliere
Now that the driver core can properly handle constant struct bus_type, move the scmi_bus_type variable to be a constant structure as well, placing it into read-only memory which can not be modified at runtime. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ricardo B. Marliere <ricardo@marliere.net> Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20240211-bus_cleanup-firmware2-v1-2-1851c92c7be7@marliere.net Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-02-20firmware: arm_scmi: Fix double free in SMC transport cleanup pathAndre Przywara
When the generic SCMI code tears down a channel, it calls the chan_free callback function, defined by each transport. Since multiple protocols might share the same transport_info member, chan_free() might want to clean up the same member multiple times within the given SCMI transport implementation. In this case, it is SMC transport. This will lead to a NULL pointer dereference at the second time: | scmi_protocol scmi_dev.1: Enabled polling mode TX channel - prot_id:16 | arm-scmi firmware:scmi: SCMI Notifications - Core Enabled. | arm-scmi firmware:scmi: unable to communicate with SCMI | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 | Mem abort info: | ESR = 0x0000000096000004 | EC = 0x25: DABT (current EL), IL = 32 bits | SET = 0, FnV = 0 | EA = 0, S1PTW = 0 | FSC = 0x04: level 0 translation fault | Data abort info: | ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 | CM = 0, WnR = 0, TnD = 0, TagAccess = 0 | GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 | user pgtable: 4k pages, 48-bit VAs, pgdp=0000000881ef8000 | [0000000000000000] pgd=0000000000000000, p4d=0000000000000000 | Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP | Modules linked in: | CPU: 4 PID: 1 Comm: swapper/0 Not tainted 6.7.0-rc2-00124-g455ef3d016c9-dirty #793 | Hardware name: FVP Base RevC (DT) | pstate: 61400009 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) | pc : smc_chan_free+0x3c/0x6c | lr : smc_chan_free+0x3c/0x6c | Call trace: | smc_chan_free+0x3c/0x6c | idr_for_each+0x68/0xf8 | scmi_cleanup_channels.isra.0+0x2c/0x58 | scmi_probe+0x434/0x734 | platform_probe+0x68/0xd8 | really_probe+0x110/0x27c | __driver_probe_device+0x78/0x12c | driver_probe_device+0x3c/0x118 | __driver_attach+0x74/0x128 | bus_for_each_dev+0x78/0xe0 | driver_attach+0x24/0x30 | bus_add_driver+0xe4/0x1e8 | driver_register+0x60/0x128 | __platform_driver_register+0x28/0x34 | scmi_driver_init+0x84/0xc0 | do_one_initcall+0x78/0x33c | kernel_init_freeable+0x2b8/0x51c | kernel_init+0x24/0x130 | ret_from_fork+0x10/0x20 | Code: f0004701 910a0021 aa1403e5 97b91c70 (b9400280) | ---[ end trace 0000000000000000 ]--- Simply check for the struct pointer being NULL before trying to access its members, to avoid this situation. This was found when a transport doesn't really work (for instance no SMC service), the probe routines then tries to clean up, and triggers a crash. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Fixes: 1dc6558062da ("firmware: arm_scmi: Add smc/hvc transport") Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20240126122325.2039669-1-andre.przywara@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-02-20firmware: arm_scmi: Implement clock get permissionsPeng Fan
ARM SCMI v3.2 introduces clock get permission command. To implement the same let us stash the values of those permissions in the scmi_clock_info. They indicate if the operation is forbidden or not. If the CLOCK_GET_PERMISSIONS command is not supported, the default permissions are set to allow the operations, otherwise they will be set according to the response of CLOCK_GET_PERMISSIONS from the SCMI platform firmware. Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Peng Fan <peng.fan@nxp.com> Link: https://lore.kernel.org/r/20240121110901.1414856-1-peng.fan@oss.nxp.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-02-20firmware: arm_scmi: Add multiple protocols registration supportCristian Marussi
Add the capability for a SCMI driver to register to the core SCMI stack with multiple SCMI protocols. In such a case the SCMI driver probe function will end up being called once for each registered protocol which have been also found as implemented on the platform. This is especially useful in testing scenarios. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20231221151129.325749-1-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-02-20firmware: arm_scmi: Rework clock domain info lookupsCristian Marussi
Accessing clock domains descriptors by the index from the SCMI drivers can potentially lead to out-of-bound violations if the SCMI drivers misbehaves. Use a common helper to check the consistency of such accesses. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20240110120916.2482603-1-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-02-20firmware: arm_scmi: Warn if domain frequency multiplier is 0 or rounded offSudeep Holla
When (sustained_freq_khz * 1000) is less than sustained_perf_level, the multiplier will be less than 1 and hence rounded down as 0. Similarly if it is not multiple of sustained_perf_level the dom_info->mult_factor will contain rounded down value and will end up impacting all the frequency calculations done using it. Add warning if and when the domain frequency multiplier is 0 or rounded down so that it gives a clue to get the firmware tables fixed. Suggested-by: Pierre Gondois <Pierre.Gondois@arm.com> Reviewed-by: Pierre Gondois <pierre.gondois@arm.com> Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20240119152338.3047620-1-sudeep.holla@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-02-07MAINTAINERS: Remove Tomasz from Samsung clock and pinctrl entriesTomasz Figa
I have been no longer at Samsung for a long time, the platforms that I am knowledgable about (S3C24xx, S3C64xx, Exynos 4) are no longer relevant and we have people with better capabilities as maintainers already, so let me remove myself. Thanks for the nice collaboration everyone! Signed-off-by: Tomasz Figa <tomasz.figa@gmail.com> Link: https://lore.kernel.org/r/20240201140134.4345-1-tomasz.figa@gmail.com Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2024-02-07dt-bindings: samsung: exynos-sysreg: gs101-peric0/1 require a clockAndré Draszik
... otherwise it won't be accessible. Update the schema to make this obvious. Signed-off-by: André Draszik <andre.draszik@linaro.org> Link: https://lore.kernel.org/r/20240126115517.1751971-1-andre.draszik@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2024-01-31soc: renesas: rcar-rst: Add support for R-Car V4MDuy Nguyen
Add support for the R-Car V4M (R8A779H0) SoC to the R-Car RST driver. Signed-off-by: Duy Nguyen <duy.nguyen.rh@renesas.com> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Link: https://lore.kernel.org/r/13dc9f014e27db5092b3cc23edddf4b5e01a6645.1706194617.git.geert+renesas@glider.be
2024-01-31soc: renesas: Identify R-Car V4MDuy Nguyen
Add support for identifying the R-Car V4M (R8A779H0) SoC. Signed-off-by: Duy Nguyen <duy.nguyen.rh@renesas.com> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Link: https://lore.kernel.org/r/31e06d055aec1bc70c3e9a02f9268bcfc72b2204.1706194617.git.geert+renesas@glider.be
2024-01-31soc: renesas: Introduce ARCH_RCAR_GEN4Geert Uytterhoeven
Currently, all Kconfig symbols for R-Car Gen4 SoCs select the ARCH_RCAR_GEN3 SoC family symbol, which might confuse the casual reader. Fix this by introducing a new SoC family symbol for R-Car Gen4 SoCs. For now this just selects ARCH_RCAR_GEN3, to avoid duplication, and to relax dependencies. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Link: https://lore.kernel.org/r/a283913ba7a39ec2dae0ebf9fc2b06096f009511.1706194617.git.geert+renesas@glider.be
2024-01-31soc: mediatek: mtk-socinfo: Add extra entry for MT8183Chen-Yu Tsai
The MT8183 has another socinfo match, with the second cell only differing by one bit. Add it to the driver. Fixes: 423a54da3c7e ("soc: mediatek: mtk-socinfo: Add driver for getting chip information") Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Acked-by: William-tw Lin <william-tw.lin@mediatek.com> Link: https://lore.kernel.org/r/20240130095656.3712469-3-wenst@chromium.org Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2024-01-31soc: mediatek: mtk-socinfo: Clean up NVMEM cell readChen-Yu Tsai
The mtk-socinfo grabs the NVMEM device devm_nvmem_device_get(), but then proceeds to put the device directly with nvmem_device_put() if the read is successful. If the device fails to probe and goes through the devres release path, the device would be put a second time, triggering a use-after-free error from KASAN. Fix this by dropping the devres part. Since the NVMEM cell data is read only once, there is no need to keep the reference around. While at it, clean up the function to directly reference the NVMEM device node and use that to find the NVMEM device, instead of finding it by name, which is more fragile. The cell node is always a direct child of the NVMEM device node, courtesy of the legacy NVMEM cell layout. Thus of_get_child_by_name() is a better way of finding the cell. Last, correctly put the device node once its use is over. Fixes: 423a54da3c7e ("soc: mediatek: mtk-socinfo: Add driver for getting chip information") Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20240130095656.3712469-2-wenst@chromium.org Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2024-01-29soc: mediatek: mtk-socinfo: Add driver for getting chip informationWilliam-tw Lin
Add driver for socinfo retrieval. This patch includes the following: 1. mtk-socinfo driver for chip info retrieval 2. Related changes to Makefile and Kconfig Signed-off-by: William-tw Lin <william-tw.lin@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20231222080739.21706-3-william-tw.lin@mediatek.com Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2024-01-25dt-bindings: memory-controllers: narrow regex for unit address to hex numbersKrzysztof Kozlowski
Regular expression used to match the unit address part should not allow non-hex numbers. Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Link: https://lore.kernel.org/r/20240123083517.21091-1-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2024-01-23memory: emif: Drop usage of platform_driver_probe()Uwe Kleine-König
There are considerations to drop platform_driver_probe() as a concept that isn't relevant any more today. It comes with an added complexity that makes many users hold it wrong. (E.g. this driver should have better used __init instead of __init_or_module to mark functions only relevant to .probe() and mark the driver struct with __refdata.) This fixes a W=1 build warning: WARNING: modpost: drivers/memory/emif: section mismatch in reference: emif_driver+0x4 (section: .data) -> emif_remove (section: .exit.text) Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20240123170846.1362597-2-u.kleine-koenig@pengutronix.de Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2024-01-23memory: emif: Simplify code handling CONFIG_OFUwe Kleine-König
The first thing that of_get_memory_device_details() does is calling of_parse_phandle(). With CONFIG_OF=n this returns NULL in a static inline function. So the compiler can determine that of_get_memory_device_details() also returns NULL. bloat-o-meter confirms that this patch has no effects on the size of the generated code for CONFIG_OF=n builds. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/9d53683c34a730c8579a1468b643b11d1379106e.1702829744.git.u.kleine-koenig@pengutronix.de Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2024-01-23memory: emif: Simplify code handling CONFIG_DEBUG_FSUwe Kleine-König
Instead of using #ifdef make use of IS_ENABLED(). According to bloat-o-meter this patch doesn't change code sizes with CONFIG_DEBUG_FS=n. Also change emif_debugfs_init() to return void. The only caller doesn't check the return value anyhow. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/2c7dd66d4a101b74b16e7e1839e30f3c88510c33.1702829744.git.u.kleine-koenig@pengutronix.de Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2024-01-22dt-bindings: i2c: exynos5: add google,gs101-hsi2c compatibleTudor Ambarus
Add google,gs101-hsi2c dedicated compatible for representing I2C of Google GS101 SoC. Acked-by: Wolfram Sang <wsa@kernel.org> Acked-by: Rob Herring <robh@kernel.org> Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org> Reviewed-by: Peter Griffin <peter.griffin@linaro.org> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org> Link: https://lore.kernel.org/r/20240119111132.1290455-3-tudor.ambarus@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2024-01-22firmware: arm_scmi: Fix the clock protocol supported versionCristian Marussi
Rollback currently supported SCMI clock protocol version to v2.0 since some of the mandatory v3.0 features are indeed still not supported yet. Fixes: b5efc28a754d ("firmware: arm_scmi: Add protocol versioning checks") Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20240109181716.2338636-1-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-01-22firmware: arm_scmi: Fix the clock protocol version for v3.2Cristian Marussi
The clock protocol version as per the SCMI v3.2 specification is 0x30000. Enable the v3.0 clock protocol features only when clock protocol version equals 0x30000. The previous beta version of the spec had this value set to 0x20001 and th same value trickled down from the initial development. The version update were missed in the driver. Fixes: e49e314a2cf7 ("firmware: arm_scmi: Add clock v3.2 CONFIG_SET support") Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20240109150106.2066739-1-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-01-22firmware: arm_scmi: Use xa_insert() when saving raw queuesCristian Marussi
Use xa_insert() when saving per-channel raw queues to better check for duplicates. Fixes: 7860701d1e6e ("firmware: arm_scmi: Add per-channel raw injection support") Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20240108185050.1628687-2-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-01-22firmware: arm_scmi: Use xa_insert() to store oppsCristian Marussi
When storing opps by level or index use xa_insert() instead of xa_store() and add error-checking to spot bad duplicates indexes possibly wrongly provided by the platform firmware. Fixes: 31c7c1397a33 ("firmware: arm_scmi: Add v3.2 perf level indexing mode support") Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20240108185050.1628687-1-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-01-22firmware: arm_scmi: Replace asm-generic/bug.h with linux/bug.hTanzir Hasan
linux/bug.h includes asm-generic/bug.h already and hence replacing asm-generic/bug.h with linux/bug.h will not regress any build. Also, it is always better to avoid header file inclusion from asm-generic if possible. Suggested-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Tanzir Hasan <tanzirh@google.com> Link: https://lore.kernel.org/r/20231226-shmem-v1-1-ea15ce81d8ba@google.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-01-22firmware: arm_scmi: Check mailbox/SMT channel for consistencyCristian Marussi
On reception of a completion interrupt the shared memory area is accessed to retrieve the message header at first and then, if the message sequence number identifies a transaction which is still pending, the related payload is fetched too. When an SCMI command times out the channel ownership remains with the platform until eventually a late reply is received and, as a consequence, any further transmission attempt remains pending, waiting for the channel to be relinquished by the platform. Once that late reply is received the channel ownership is given back to the agent and any pending request is then allowed to proceed and overwrite the SMT area of the just delivered late reply; then the wait for the reply to the new request starts. It has been observed that the spurious IRQ related to the late reply can be wrongly associated with the freshly enqueued request: when that happens the SCMI stack in-flight lookup procedure is fooled by the fact that the message header now present in the SMT area is related to the new pending transaction, even though the real reply has still to arrive. This race-condition on the A2P channel can be detected by looking at the channel status bits: a genuine reply from the platform will have set the channel free bit before triggering the completion IRQ. Add a consistency check to validate such condition in the A2P ISR. Reported-by: Xinglong Yang <xinglong.yang@cixtech.com> Closes: https://lore.kernel.org/all/PUZPR06MB54981E6FA00D82BFDBB864FBF08DA@PUZPR06MB5498.apcprd06.prod.outlook.com/ Fixes: 5c8a47a5a91d ("firmware: arm_scmi: Make scmi core independent of the transport type") Cc: stable@vger.kernel.org # 5.15+ Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Tested-by: Xinglong Yang <xinglong.yang@cixtech.com> Link: https://lore.kernel.org/r/20231220172112.763539-1-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-01-21Linux 6.8-rc1Linus Torvalds