Merge tag 'scmi-updates-6.9' of 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.comSigned-off-by: Arnd Bergmann <arnd@arndb.de>

Merge tag 'ffa-update-6.9' of 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.comSigned-off-by: Arnd Bergmann <arnd@arndb.de>

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.comSigned-off-by: Sudeep Holla <sudeep.holla@arm.com>

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.comSigned-off-by: Sudeep Holla <sudeep.holla@arm.com>

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.comSigned-off-by: Sudeep Holla <sudeep.holla@arm.com>

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.comSigned-off-by: Sudeep Holla <sudeep.holla@arm.com>

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.comSigned-off-by: Sudeep Holla <sudeep.holla@arm.com>

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.orgSigned-off-by: Sudeep Holla <sudeep.holla@arm.com>

Merge tag 'memory-controller-drv-6.9' of 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.orgSigned-off-by: Arnd Bergmann <arnd@arndb.de>

Merge tag 'samsung-drivers-6.9' of 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.orgSigned-off-by: Arnd Bergmann <arnd@arndb.de>

Merge tag 'renesas-drivers-for-v6.9-tag1' of 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.beSigned-off-by: Arnd Bergmann <arnd@arndb.de>

Merge tag 'mtk-soc-for-v6.9' of 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.comSigned-off-by: Arnd Bergmann <arnd@arndb.de>

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.comSigned-off-by: Sudeep Holla <sudeep.holla@arm.com>

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.comSigned-off-by: Sudeep Holla <sudeep.holla@arm.com>

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.comSigned-off-by: Sudeep Holla <sudeep.holla@arm.com>

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.comSigned-off-by: Sudeep Holla <sudeep.holla@arm.com>

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.comSigned-off-by: Sudeep Holla <sudeep.holla@arm.com>

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.comSigned-off-by: Sudeep Holla <sudeep.holla@arm.com>

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.netSigned-off-by: Sudeep Holla <sudeep.holla@arm.com>

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.comSigned-off-by: Sudeep Holla <sudeep.holla@arm.com>

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.comSigned-off-by: Sudeep Holla <sudeep.holla@arm.com>

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.comSigned-off-by: Sudeep Holla <sudeep.holla@arm.com>

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.comSigned-off-by: Sudeep Holla <sudeep.holla@arm.com>

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.comSigned-off-by: Sudeep Holla <sudeep.holla@arm.com>

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.netSigned-off-by: Sudeep Holla <sudeep.holla@arm.com>

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: 1dc65580 ("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.comSigned-off-by: Sudeep Holla <sudeep.holla@arm.com>

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.comSigned-off-by: Sudeep Holla <sudeep.holla@arm.com>

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.comSigned-off-by: Sudeep Holla <sudeep.holla@arm.com>

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.comSigned-off-by: Sudeep Holla <sudeep.holla@arm.com>

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.comSigned-off-by: Sudeep Holla <sudeep.holla@arm.com>

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.comSigned-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

... 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.orgSigned-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

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

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

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

The MT8183 has another socinfo match, with the second cell only
differing by one bit. Add it to the driver.

Fixes: 423a54da ("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.orgSigned-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>

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: 423a54da ("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.orgSigned-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>

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.comSigned-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>

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.orgSigned-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

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.deSigned-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>