* Re: [PATCH 1/2] dt-bindings: usb: Add Rockchip RK3568 compatible for EHCI and OHCI
From: Conor Dooley @ 2026-06-09 15:56 UTC (permalink / raw)
To: Jonas Karlman
Cc: Heiko Stuebner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Greg Kroah-Hartman, Diederik de Haas, devicetree, linux-rockchip,
linux-usb, linux-arm-kernel, linux-kernel
In-Reply-To: <20260609154124.445182-2-jonas@kwiboo.se>
[-- Attachment #1: Type: text/plain, Size: 640 bytes --]
On Tue, Jun 09, 2026 at 03:41:22PM +0000, Jonas Karlman wrote:
> The Rockchip RK3568 EHCI/OHCI controller depends on clk_usbphy1_480m
> being enabled, or the system may freeze when registers are accessed.
>
> Add Rockchip RK3568 EHCI and OHCI compatibles with a similar four-clock
> constraint as RK3588.
>
> Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
> ---
> Existing DTs for RK3568 use the plain generic-ehci/ohci compatible,
> next patch make use of these new compatibles and adds the missing
> clk_usbphy1_480m clock references.
Reasonable complaint here from Sashiko.
pw-bot: changes-requested
Cheers,
Conor.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/4] dt-bindings: iio: adc: mediatek,mt6359-auxadc: add mt6323 PMIC AUXADC
From: Conor Dooley @ 2026-06-09 16:01 UTC (permalink / raw)
To: rva333
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Lee Jones, linux-iio, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek, Ben Grisdale
In-Reply-To: <20260609-mt6323-adc-v2-1-aa93a22309f9@protonmail.com>
[-- Attachment #1: Type: text/plain, Size: 3739 bytes --]
On Tue, Jun 09, 2026 at 04:31:58PM +0300, Roman Vivchar via B4 Relay wrote:
> From: Roman Vivchar <rva333@protonmail.com>
>
> The MediaTek mt6323 PMIC includes an AUXADC used for battery voltage,
> temperature, and other internal measurements.
>
> Add the devicetree binding documentation and the associated header file
> defining the ADC channel constants.
>
> Also change the description to 'MT6350 series and similar' because
> the binding already includes more than mt635x series PMICs.
>
> Finally, add the MAINTAINERS entry for the header with ADC constants.
>
> Signed-off-by: Roman Vivchar <rva333@protonmail.com>
> ---
> .../bindings/iio/adc/mediatek,mt6359-auxadc.yaml | 3 ++-
> MAINTAINERS | 6 ++++++
> .../dt-bindings/iio/adc/mediatek,mt6323-auxadc.h | 24 ++++++++++++++++++++++
> 3 files changed, 32 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/mediatek,mt6359-auxadc.yaml b/Documentation/devicetree/bindings/iio/adc/mediatek,mt6359-auxadc.yaml
> index 5d4ab701f51a..852eb7336a5a 100644
> --- a/Documentation/devicetree/bindings/iio/adc/mediatek,mt6359-auxadc.yaml
> +++ b/Documentation/devicetree/bindings/iio/adc/mediatek,mt6359-auxadc.yaml
> @@ -4,7 +4,7 @@
> $id: http://devicetree.org/schemas/iio/adc/mediatek,mt6359-auxadc.yaml#
> $schema: http://devicetree.org/meta-schemas/core.yaml#
>
> -title: MediaTek MT6350 series PMIC AUXADC
> +title: MediaTek MT6350 series and similar PMIC AUXADC
>
> maintainers:
> - AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> @@ -19,6 +19,7 @@ description:
> properties:
> compatible:
> enum:
> + - mediatek,mt6323-auxadc
Commit message needs to explain why a fallback is not suitable.
pw-bot: changes-requested
> - mediatek,mt6357-auxadc
> - mediatek,mt6358-auxadc
> - mediatek,mt6359-auxadc
> diff --git a/MAINTAINERS b/MAINTAINERS
> index d1cc0e12fe1f..2551c8cd9e9d 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -16256,6 +16256,12 @@ S: Maintained
> F: Documentation/devicetree/bindings/mmc/mtk-sd.yaml
> F: drivers/mmc/host/mtk-sd.c
>
> +MEDIATEK MT6323 PMIC AUXADC DRIVER
> +M: Roman Vivchar <rva333@protonmail.com>
> +L: linux-iio@vger.kernel.org
> +S: Maintained
> +F: include/dt-bindings/iio/adc/mediatek,mt6323-auxadc.h
Why is the binding not being included here?
Cheers,
Conor.
> +
> MEDIATEK MT6735 CLOCK & RESET DRIVERS
> M: Yassine Oudjana <y.oudjana@protonmail.com>
> L: linux-clk@vger.kernel.org
> diff --git a/include/dt-bindings/iio/adc/mediatek,mt6323-auxadc.h b/include/dt-bindings/iio/adc/mediatek,mt6323-auxadc.h
> new file mode 100644
> index 000000000000..6ee9a9ecffc1
> --- /dev/null
> +++ b/include/dt-bindings/iio/adc/mediatek,mt6323-auxadc.h
> @@ -0,0 +1,24 @@
> +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
> +
> +#ifndef _DT_BINDINGS_MEDIATEK_MT6323_AUXADC_H
> +#define _DT_BINDINGS_MEDIATEK_MT6323_AUXADC_H
> +
> +#define MT6323_AUXADC_BATON2 0
> +#define MT6323_AUXADC_CH6 1
> +#define MT6323_AUXADC_BAT_TEMP 2
> +#define MT6323_AUXADC_CHIP_TEMP 3
> +#define MT6323_AUXADC_VCDT 4
> +#define MT6323_AUXADC_BATON1 5
> +#define MT6323_AUXADC_ISENSE 6
> +#define MT6323_AUXADC_BATSNS 7
> +#define MT6323_AUXADC_ACCDET 8
> +#define MT6323_AUXADC_AUDIO0 9
> +#define MT6323_AUXADC_AUDIO1 10
> +#define MT6323_AUXADC_AUDIO2 11
> +#define MT6323_AUXADC_AUDIO3 12
> +#define MT6323_AUXADC_AUDIO4 13
> +#define MT6323_AUXADC_AUDIO5 14
> +#define MT6323_AUXADC_AUDIO6 15
> +#define MT6323_AUXADC_AUDIO7 16
> +
> +#endif
>
> --
> 2.54.0
>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH net-next v6 06/12] net: Document PCS subsystem
From: Christian Marangi @ 2026-06-09 15:12 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Simon Horman, Jonathan Corbet, Shuah Khan, Christian Marangi,
Lorenzo Bianconi, Heiner Kallweit, Russell King, Saravana Kannan,
Philipp Zabel, Nathan Chancellor, Nick Desaulniers, Bill Wendling,
Justin Stitt, netdev, devicetree, linux-kernel, linux-doc,
linux-arm-kernel, linux-mediatek, llvm
In-Reply-To: <20260609151212.29469-1-ansuelsmth@gmail.com>
Add extensive documentation of the new PCS subsystem and the fwnode
implementation with producer/consumer API.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
---
Documentation/networking/index.rst | 1 +
Documentation/networking/pcs.rst | 228 +++++++++++++++++++++++++++++
2 files changed, 229 insertions(+)
create mode 100644 Documentation/networking/pcs.rst
diff --git a/Documentation/networking/index.rst b/Documentation/networking/index.rst
index 44a422ad3b05..3fce8f6ac089 100644
--- a/Documentation/networking/index.rst
+++ b/Documentation/networking/index.rst
@@ -28,6 +28,7 @@ Contents:
net_failover
page_pool
phy
+ pcs
sfp-phylink
alias
bridge
diff --git a/Documentation/networking/pcs.rst b/Documentation/networking/pcs.rst
new file mode 100644
index 000000000000..9436ba43cebd
--- /dev/null
+++ b/Documentation/networking/pcs.rst
@@ -0,0 +1,228 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=============
+PCS Subsystem
+=============
+
+The PCS (Physical Coding Sublayer) subsystem handles the registration and lookup
+of PCS devices. These devices contain the upper sublayers of the Ethernet
+physical layer, generally handling framing, scrambling, and encoding tasks. PCS
+devices may also include PMA (Physical Medium Attachment) components. PCS
+devices transfer data between the Link-layer MAC device, and the rest of the
+physical layer, typically via a serdes. The output of the serdes may be
+connected more-or-less directly to the medium when using fiber-optic or
+backplane connections (1000BASE-SX, 1000BASE-KX, etc). It may also communicate
+with a separate PHY (such as over SGMII) which handles the connection to the
+medium (such as 1000BASE-T).
+
+Remark on usage of .mac_select_pcs and fw_node PCS
+--------------------------------------------------
+
+There are generally two ways to look up a PCS device.
+
+1. MAC OP struct .mac_select_pcs (considered legacy)
+2. firmware node (fwnode) PCS entirely handled by phylink
+
+Implementation 1 leaves the entire handling of the PCS to the MAC
+driver with the selection of the PCS driven by .mac_select_pcs.
+Custom implementations are required if the PCS is external to the MAC
+and needs to be handled by a separate driver.
+
+This implementation is considered legacy and it's suggested to
+switch to the new fwnode PCS.
+
+Looking up PCS Devices (fwnode implementation)
+-----------------------------------------------
+
+The lookup of a PCS device follows the common producer/consumer implementation
+used by similar subsystem with a ``#pcs-cells`` on the producer and a
+``pcs-handle`` property on the consumer::
+
+ pcs: pcs {
+ // ...
+ #pcs-cells = <0>;
+ };
+
+ ethernet-controller {
+ // ...
+ pcs-handle = <&pcs>;
+ };
+
+On :c:func:`phylink_create`, phylink will use the ``num_available_pcs``
+value and ``fill_available_pcs`` helper function in
+:c:struct:`phylink_config` to compose the list of available PCS that can be
+used for the phylink instance.
+
+Phylink will then internally handle the selection of the correct PCS for
+the requested interface mode based on the interface modes configured in
+``pcs_interfaces`` in :c:struct:`phylink_config` struct and
+``supported_interfaces`` in :c:struct:`phylink_pcs` struct.
+
+A PCS is considered eligible when the requested interface mode is present
+in both ``pcs_interfaces`` in :c:struct:`phylink_config` struct and
+``supported_interfaces`` in :c:struct:`phylink_pcs` struct.
+
+``supported_interfaces`` describes all interface modes supported by the MAC,
+whereas ``pcs_interfaces`` identifies the subset that require PCS selection.
+
+For the special implementation where the PCS is internal or part of the MAC
+and a dedicated driver is not needed, it's possible to leave the implementation
+of the PCS to the MAC driver and just implement the ``num_available_pcs``
+value and ``fill_available_pcs`` helper function in
+:c:struct:`phylink_config` referencing the local :c:struct:`phylink_pcs`
+struct allocated from the MAC driver.
+
+Using PCS Devices
+-----------------
+
+It's mandatory to either implement the ``mac_select_pcs`` callback
+of :c:struct:`phylink_mac_ops` or ``num_available_pcs`` and ``fill_available_pcs`` of :c:struct:`phylink_config` to use a PCS
+for a MAC.
+
+The fwnode implementation expose a simple helper to parse the PCS from
+the fwnode :c:func:`fwnode_phylink_pcs_parse`. The helper takes three arguments,
+the fwnode where the ``pcs-handle`` should be parsed, an allocated array
+of :c:struct:`phylink_pcs` pointer where to put the parsed PCS from the fwnode
+and a pointer to the maximum number of PCS to parse. The helper can also be used
+to obtain the number of PCS parsed (without filling the array) by passing
+``NULL`` for the second arg. In such case, the third arg will be set to the
+number of PCS parsed in the fwnode.
+
+A phylink instance may use multiple PCS devices. The maximum number is reported
+through ``num_available_pcs``.
+
+It's mandatory to specify for what interface a PCS is needed. This can be done
+by filling the ``pcs_interfaces`` in :c:struct:`phylink_config` struct.
+If the requested interface mode is not present in this bitmask, phylink does
+not search for a PCS for that specific mode. (example MAC doesn't need a PCS
+for SGMII but require one for USXGMII)
+
+With the use of the :c:func:`fwnode_phylink_pcs_parse` a common implementation
+is the following::
+
+ static int mac_fill_available_pcs(struct phylink_config *config,
+ struct phylink_pcs **available_pcs,
+ unsigned int num_available_pcs)
+ {
+ struct device *dev = config->dev;
+
+ return fwnode_phylink_pcs_parse(dev_fwnode(dev), available_pcs,
+ &num_available_pcs);
+ }
+
+ static int mac_setup_phylink(struct net_device *netdev)
+ {
+ struct phylink_config *config;
+
+ // ...
+
+ config->dev = &netdev->dev;
+
+ // ...
+
+ // Parse available PCS and fill num_available_pcs.
+ err = fwnode_phylink_pcs_parse(dev_fwnode(&netdev->dev), NULL,
+ &config->num_available_pcs);
+ if (err)
+ return err;
+
+ config->fill_available_pcs = mac_fill_available_pcs;
+
+ __set_bit(PHY_INTERFACE_MODE_INTERNAL, config->supported_interfaces);
+ __set_bit(PHY_INTERFACE_MODE_SGMII, config->supported_interfaces);
+ __set_bit(PHY_INTERFACE_MODE_1000BASEX, config->supported_interfaces);
+ __set_bit(PHY_INTERFACE_MODE_USXGMII, config->supported_interfaces);
+
+ // PCS required only for USXGMII
+ __set_bit(PHY_INTERFACE_MODE_USXGMII, config->pcs_interfaces);
+
+ phylink = phylink_create(config, //...
+
+It's worth to mention that it's phylink code that takes care of allocating
+the array of :c:struct:`phylink_pcs` pointer for ``fill_available_pcs``
+callback based on the value set in ``num_available_pcs`` for
+:c:struct:`phylink_config` struct.
+
+The ``fill_available_pcs`` callback must not write more than
+``num_available_pcs`` entries. The third argument may be used to validate
+that there is enough space to fill all the available PCS in the passed array
+of :c:struct:`phylink_pcs` pointer.
+
+The ``fill_available_pcs`` callback is called only on :c:func:`phylink_create`
+and is used only to compose the initial available PCS list. Ownership of PCS
+is held by phylink and :c:func:`phylink_release_pcs` should be used to relase
+them.
+
+Writing PCS Drivers
+-------------------
+
+To write a PCS driver, first implement :c:struct:`phylink_pcs_ops`. Then,
+register your PCS in your probe function using :c:func:`fwnode_pcs_add_provider`.
+The :c:func:`fwnode_pcs_add_provider` takes three arg, the fwnode where the PCS
+provider should be registered to, a get function to return the requested PCS
+based on ``#pcs-cells`` and a pointer to reference private data for the get
+function.
+
+The PCS will then be registered to a global list of PCS provider that the
+PCS fwnode implementation will use to parse it.
+
+For the simple case where the PCS driver expose a single PCS,
+:c:func:`fwnode_pcs_simple_get` can be used as the get function.
+
+You must call :c:func:`fwnode_pcs_del_provider` from your remove function and
+release the PCS from any phylink instance under RTNL lock with
+:c:func:`phylink_release_pcs`::
+
+ fwnode_pcs_del_provider(dev_fwnode(&pdev->dev));
+
+ rtnl_lock();
+
+ for (i = 0; i < data->num_port; i++) {
+ struct pcs_port *port = &priv->ports[i];
+
+ phylink_release_pcs(&port->pcs);
+ }
+
+ rtnl_unlock();
+
+Late PCS registration handling
+------------------------------
+
+It's possible that a PCS becomes available after the MAC finished probing.
+Contrary to the usual producer/consumer implementation, when a PCS is not
+registered and can't be found, the fwnode parser helper returns ``-EINVAL``
+instead of ``-EPROBE_DEFER``.
+
+This is to prevent race condition with particular devices that register
+MAC and PCS with USB or PCIe and require the MAC to be registered before
+the PCS.
+
+The phylink logic correctly handle this special case and keep the phylink
+instance in a fail condition.
+
+The PCS fwnode implementation provides a notifier to which each phylink
+instance with a non-empty ``pcs_interfaces`` in :c:type:`phylink_config`
+registers. When a new PCS provider is registered, the notifier is called
+triggering the :c:func:`pcs_provider_notify` function.
+
+Function :c:func:`pcs_provider_notify` will check if the just added PCS
+should be used by the phylink instance. If it should be used then,
+it's added to the internal list of available PCS and a phylink major
+config is forced.
+
+If a phylink instance was in a failure state, with the just added PCS
+now part of the available PCS internal phylink list, provided all other
+conditions are satisfied, the configuration is retried and the failure
+condition is cleared.
+
+API Reference
+-------------
+
+.. kernel-doc:: include/linux/phylink.h
+ :identifiers: phylink_pcs
+
+.. kernel-doc:: include/linux/pcs/pcs.h
+ :internal:
+
+.. kernel-doc:: include/linux/pcs/pcs-provider.h
+ :internal:
--
2.53.0
^ permalink raw reply related
* Re: [GIT PULL] ARM: mvebu: dt64 for v7.2 (#1)
From: Arnd Bergmann @ 2026-06-09 16:11 UTC (permalink / raw)
To: Gregory Clement, arm, soc
Cc: Andrew Lunn, Sebastian Hesselbarth, linux-arm-kernel,
Aleksander Jan Bajkowski
In-Reply-To: <8733z1c8uj.fsf@BLaptop.bootlin.com>
On Fri, Jun 5, 2026, at 17:20, Gregory CLEMENT wrote:
>
> ----------------------------------------------------------------
> mvebu dt64 for 7.2 (part 1)
>
> Mark EIP97 as dma-coherent for Armada 3720
>
> ----------------------------------------------------------------
> Aleksander Jan Bajkowski (1):
> arm64: dts: marvell: armada-37xx: mark EIP97 as dma-coherent
Hi Gregory and Aleksander,
I'm a bit surprised by this oneline change. Since you successfully tested
this, I assume the change is correct, but I have two questions that
I would like to have an answer for before I pull it.
- I would expect a missing 'dma-coherent' property to cause data
corruption, as the DMA master may write directly into the L2
cache, which is then invalidated before the CPU accesses it.
Do you have any idea how this one ends up working even when
the property is missing?
- I see that the Product Brief for Armada 37xx mentions that it
has a "High-bandwidth, low-latency IO Cache Coherency" interconnect,
which also indicates that the patch is correct. However I don't
see why it's only the crypto engine that needs it. What about
the other high-speed DMA masters (neta, xhci, pcie, sata, ...)?
Arnd
^ permalink raw reply
* Re: [PATCH v5 1/3] dt-bindings: arm: fsl: add Variscite DART-MX8M PLUS Boards
From: Conor Dooley @ 2026-06-09 16:15 UTC (permalink / raw)
To: Stefano Radaelli
Cc: linux-kernel, devicetree, imx, linux-arm-kernel, pierluigi.p,
Stefano Radaelli, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Shawn Guo, Daniel Baluta, Josua Mayer, Dario Binacchi,
Maud Spierings, Alexander Stein, Ernest Van Hoecke,
Francesco Dolcini, Hugo Villeneuve, Conor Dooley
In-Reply-To: <c65129896fc6ce80044ee1d89e12dcdff34945be.1780998600.git.stefano.r@variscite.com>
[-- Attachment #1: Type: text/plain, Size: 4029 bytes --]
On Tue, Jun 09, 2026 at 11:51:18AM +0200, Stefano Radaelli wrote:
> From: Stefano Radaelli <stefano.r@variscite.com>
>
> Add DT compatible strings for Variscite DART-MX8MP SoM and Variscite
> development carrier Board.
>
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
> Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
My mailbox looking like
| 169 ND Jun 09 Stefano Radaell ( 27K) ┌─>[PATCH v5 3/3] arm64: dts: imx8mp-var-dart: Add support for Variscite Sonata board
| 170 ND Jun 09 sashiko-bot@ker (7.2K) │ ┌─>
| 171 ND Jun 09 Stefano Radaell ( 24K) ├─>[PATCH v5 2/3] arm64: dts: freescale: Add support for Variscite DART-MX8M-PLUS
| 172 D Jun 09 Stefano Radaell ( 43) ├─>[PATCH v5 1/3] dt-bindings: arm: fsl: add Variscite DART-MX8M PLUS Boards
| 173 ND Jun 09 Stefano Radaell ( 10K) [PATCH v5 0/3] Add support for Variscite DART-MX8M-PLUS and Sonata board
| 174 ND Jun 09 sashiko-bot@ker (7.1K) ┌─>
| 175 ND Jun 09 Hongliang Wang (7.8K) ┌─>[PATCH v1 2/3] LoongArch: dts: i2c: Add clocks and clock-frequency properties to 2K1000
| 176 ND Jun 09 Hongliang Wang (8.9K) ├─>[PATCH v1 1/3] LoongArch: dts: i2c: Add clocks and clock-frequency properties to 2K0500
| 177 ND Jun 09 Hongliang Wang (7.7K) ├─>[PATCH v1 3/3] LoongArch: dts: i2c: Add clocks and clock-frequency properties to 2K2000
| 178 ND Jun 09 Hongliang Wang (7.0K) [PATCH v1 0/3] LoongArch: dts: i2c: Add clocks and clock-frequency properties
| 179 ND Jun 09 Stefano Radaell ( 27K) ┌─>[PATCH v4 3/3] arm64: dts: imx8mp-var-dart: Add support for Variscite Sonata board
| 180 ND Jun 09 sashiko-bot@ker (7.7K) │ ┌─>
| 181 ND Jun 09 Stefano Radaell ( 24K) ├─>[PATCH v4 2/3] arm64: dts: freescale: Add support for Variscite DART-MX8M-PLUS
| 182 D Jun 09 Stefano Radaell ( 40) ├─>[PATCH v4 1/3] dt-bindings: arm: fsl: add Variscite DART-MX8M PLUS Boards
| 183 ND Jun 09 Stefano Radaell ( 10K) [PATCH v4 0/3] Add support for Variscite DART-MX8M-PLUS and Sonata board
| 184 D Jun 09 Paolo Abeni ( 19) Re: [PATCH v2 1/1] dt-bindings: net: dsa: Convert lan9303.txt to yaml format
| 185 N Jun 09 Stefano Radaell ( 27K) ┌─>[PATCH v3 3/3] arm64: dts: imx8mp-var-dart: Add support for Variscite Sonata board
| 186 N Jun 09 sashiko-bot@ker (7.1K) │ ┌─>
| 187 N Jun 09 Stefano Radaell ( 24K) ├─>[PATCH v3 2/3] arm64: dts: freescale: Add support for Variscite DART-MX8M-PLUS
| 188 Jun 09 Stefano Radaell ( 36) ├─>[PATCH v3 1/3] dt-bindings: arm: fsl: add Variscite DART-MX8M PLUS Boards
| 189 N Jun 09 Stefano Radaell ( 10K) [PATCH v3 0/3] Add support for Variscite DART-MX8M-PLUS and Sonata board
is a pretty clear indication that you're iterating too quickly.
Try to slow down and leave people time to respond before sending new
versions, not just respin for every automated response you get.
Cheers,
Conor.
> ---
> v4->v5:
> -
>
> v3->v4:
> -
>
> v2->v3:
> -
>
> v1->v2:
> -
>
> Documentation/devicetree/bindings/arm/fsl.yaml | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
> index 86876311ec59..11629b9eafc5 100644
> --- a/Documentation/devicetree/bindings/arm/fsl.yaml
> +++ b/Documentation/devicetree/bindings/arm/fsl.yaml
> @@ -1310,6 +1310,12 @@ properties:
> - const: tq,imx8mp-tqma8mpql # TQ-Systems GmbH i.MX8MP TQMa8MPQL SOM
> - const: fsl,imx8mp
>
> + - description: Variscite DART-MX8M Plus based boards
> + items:
> + - const: variscite,var-dart-mx8mp-sonata # Variscite DART-MX8MP on Sonata Development Board
> + - const: variscite,var-dart-mx8mp # Variscite DART-MX8MP SOM
> + - const: fsl,imx8mp
> +
> - description: Variscite VAR-SOM-MX8M Plus based boards
> items:
> - const: variscite,var-som-mx8mp-symphony
> --
> 2.47.3
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH net-next v6 02/12] net: phylink: introduce internal phylink PCS handling
From: Christian Marangi @ 2026-06-09 15:11 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Simon Horman, Jonathan Corbet, Shuah Khan, Christian Marangi,
Lorenzo Bianconi, Heiner Kallweit, Russell King, Saravana Kannan,
Philipp Zabel, Nathan Chancellor, Nick Desaulniers, Bill Wendling,
Justin Stitt, netdev, devicetree, linux-kernel, linux-doc,
linux-arm-kernel, linux-mediatek, llvm
In-Reply-To: <20260609151212.29469-1-ansuelsmth@gmail.com>
Introduce internal handling of PCS for phylink. This is an alternative
way to .mac_select_pcs that moves the selection logic of the PCS entirely
to phylink with the usage of the supported_interface value in the PCS
struct.
MAC should now provide a callback to fill the available PCS in
phylink_config in .fill_available_pcs and fill the .num_available_pcs with
the number of elements in the array. MAC should also define a new bitmap,
pcs_interfaces, in phylink_config to define for what interface mode a
dedicated PCS is required.
On phylink_create(), an array of PCS pointer is allocated of size
.num_available_pcs from phylink_config and .fill_available_pcs from
phylink_config is called passing as args the just allocated array and
the number of available element in it.
MAC will fill this passed array with all the available PCS.
This array is then parsed and a linked list of PCS is created based on
the allocated PCS array filled by MAC via .fill_available_pcs().
Also the supported_interface value in phylink struct is updated with the
new supported_interface from the provided PCS.
On phylink_start() every PCS in phylink PCS list gets attached to the
phylink instance. This is done by setting the phylink value in
phylink_pcs struct to the phylink instance.
On phylink_stop(), every PCS in phylink PCS list is detached from the
phylink instance. This is done by setting the phylink value in
phylink_pcs struct to NULL.
phylink_validate_mac_and_pcs(), phylink_major_config() and
phylink_inband_caps() are updated to support this new implementation
with the PCS list stored in phylink.
They will make use of phylink_validate_pcs_interface() that will loop
for every PCS in the phylink PCS available list and find one that supports
the passed interface.
phylink_validate_pcs_interface() applies the same logic of .mac_select_pcs
where if a supported_interface value is not set for the PCS struct, then
it's assumed every interface is supported.
A MAC is required to implement either a .mac_select_pcs or make use of
the PCS list implementation. Implementing both will result in a fail
on MAC/PCS validation.
A MAC defining .num_available_pcs in phylink_config MUST also define a
.fill_available_pcs or phylink_create() will fail with an negative error.
phylink value in phylink_pcs struct with this implementation is used to
track from PCS side when it's attached to a phylink instance. PCS driver
will make use of this information to correctly detach from a phylink
instance if needed.
The .mac_select_pcs implementation is not changed but it's expected that
every MAC driver migrates to the new implementation to later deprecate
and remove .mac_select_pcs.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
---
drivers/net/phy/phylink.c | 185 ++++++++++++++++++++++++++++++++++----
include/linux/phylink.h | 16 ++++
2 files changed, 183 insertions(+), 18 deletions(-)
diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
index 4d59c0dd78db..4d6ffda0cdd6 100644
--- a/drivers/net/phy/phylink.c
+++ b/drivers/net/phy/phylink.c
@@ -60,6 +60,9 @@ struct phylink {
/* The link configuration settings */
struct phylink_link_state link_config;
+ /* List of available PCS */
+ struct list_head pcs_list;
+
/* What interface are supported by the current link.
* Can change on removal or addition of new PCS.
*/
@@ -154,6 +157,8 @@ static const phy_interface_t phylink_sfp_interface_preference[] = {
static DECLARE_PHY_INTERFACE_MASK(phylink_sfp_interfaces);
+static void phylink_run_resolve(struct phylink *pl);
+
/**
* phylink_set_port_modes() - set the port type modes in the ethtool mask
* @mask: ethtool link mode mask
@@ -518,22 +523,59 @@ static void phylink_validate_mask_caps(unsigned long *supported,
linkmode_and(state->advertising, state->advertising, mask);
}
+static int phylink_validate_pcs_interface(struct phylink_pcs *pcs,
+ phy_interface_t interface)
+{
+ /* If PCS define an empty supported_interfaces value, assume
+ * all interface are supported.
+ */
+ if (phy_interface_empty(pcs->supported_interfaces))
+ return 0;
+
+ /* Ensure that this PCS supports the interface mode */
+ if (!test_bit(interface, pcs->supported_interfaces))
+ return -EINVAL;
+
+ return 0;
+}
+
static int phylink_validate_mac_and_pcs(struct phylink *pl,
unsigned long *supported,
struct phylink_link_state *state)
{
- struct phylink_pcs *pcs = NULL;
unsigned long capabilities;
+ struct phylink_pcs *pcs;
+ bool pcs_found = false;
int ret;
/* Get the PCS for this interface mode */
if (pl->mac_ops->mac_select_pcs) {
+ /* Make sure either PCS internal validation or .mac_select_pcs
+ * is used. Return error if both are defined.
+ */
+ if (!list_empty(&pl->pcs_list)) {
+ phylink_err(pl, "either phylink_pcs_add() or .mac_select_pcs must be used\n");
+ return -EINVAL;
+ }
+
pcs = pl->mac_ops->mac_select_pcs(pl->config, state->interface);
if (IS_ERR(pcs))
return PTR_ERR(pcs);
+
+ pcs_found = !!pcs;
+ } else {
+ /* Check every assigned PCS and search for one that supports
+ * the interface.
+ */
+ list_for_each_entry(pcs, &pl->pcs_list, list) {
+ if (!phylink_validate_pcs_interface(pcs, state->interface)) {
+ pcs_found = true;
+ break;
+ }
+ }
}
- if (pcs) {
+ if (pcs_found) {
/* The PCS, if present, must be setup before phylink_create()
* has been called. If the ops is not initialised, print an
* error and backtrace rather than oopsing the kernel.
@@ -545,13 +587,10 @@ static int phylink_validate_mac_and_pcs(struct phylink *pl,
return -EINVAL;
}
- /* Ensure that this PCS supports the interface which the MAC
- * returned it for. It is an error for the MAC to return a PCS
- * that does not support the interface mode.
- */
- if (!phy_interface_empty(pcs->supported_interfaces) &&
- !test_bit(state->interface, pcs->supported_interfaces)) {
- phylink_err(pl, "MAC returned PCS which does not support %s\n",
+ /* Recheck PCS to handle legacy way for .mac_select_pcs */
+ ret = phylink_validate_pcs_interface(pcs, state->interface);
+ if (ret) {
+ phylink_err(pl, "selected PCS does not support %s\n",
phy_modes(state->interface));
return -EINVAL;
}
@@ -965,12 +1004,22 @@ static unsigned int phylink_inband_caps(struct phylink *pl,
phy_interface_t interface)
{
struct phylink_pcs *pcs;
+ bool pcs_found = false;
- if (!pl->mac_ops->mac_select_pcs)
- return 0;
+ if (pl->mac_ops->mac_select_pcs) {
+ pcs = pl->mac_ops->mac_select_pcs(pl->config,
+ interface);
+ pcs_found = !!pcs;
+ } else {
+ list_for_each_entry(pcs, &pl->pcs_list, list) {
+ if (!phylink_validate_pcs_interface(pcs, interface)) {
+ pcs_found = true;
+ break;
+ }
+ }
+ }
- pcs = pl->mac_ops->mac_select_pcs(pl->config, interface);
- if (!pcs)
+ if (!pcs_found)
return 0;
return phylink_pcs_inband_caps(pcs, interface);
@@ -1265,10 +1314,36 @@ static void phylink_major_config(struct phylink *pl, bool restart,
pl->major_config_failed = true;
return;
}
+ /* Find a PCS in available PCS list for the requested interface.
+ * This doesn't overwrite the previous .mac_select_pcs as either
+ * .mac_select_pcs or PCS list implementation are permitted.
+ *
+ * Skip searching if the MAC doesn't require a dedicaed PCS for
+ * the requested interface.
+ */
+ } else if (test_bit(state->interface, pl->config->pcs_interfaces)) {
+ bool pcs_found = false;
+
+ list_for_each_entry(pcs, &pl->pcs_list, list) {
+ if (!phylink_validate_pcs_interface(pcs,
+ state->interface)) {
+ pcs_found = true;
+ break;
+ }
+ }
- pcs_changed = pl->pcs != pcs;
+ if (!pcs_found) {
+ phylink_err(pl,
+ "couldn't find a PCS for %s\n",
+ phy_modes(state->interface));
+
+ pl->major_config_failed = true;
+ return;
+ }
}
+ pcs_changed = pl->pcs != pcs;
+
phylink_pcs_neg_mode(pl, pcs, state->interface, state->advertising);
phylink_dbg(pl, "major config, active %s/%s/%s\n",
@@ -1295,11 +1370,13 @@ static void phylink_major_config(struct phylink *pl, bool restart,
if (pcs_changed) {
phylink_pcs_disable(pl->pcs);
- if (pl->pcs)
- pl->pcs->phylink = NULL;
+ if (pl->mac_ops->mac_select_pcs) {
+ if (pl->pcs)
+ pl->pcs->phylink = NULL;
- if (pcs)
- pcs->phylink = pl;
+ if (pcs)
+ pcs->phylink = pl;
+ }
pl->pcs = pcs;
}
@@ -1834,6 +1911,44 @@ int phylink_set_fixed_link(struct phylink *pl,
}
EXPORT_SYMBOL_GPL(phylink_set_fixed_link);
+static int phylink_fill_available_pcs(struct phylink *pl,
+ struct phylink_config *config)
+{
+ struct phylink_pcs **pcss;
+ int i, ret;
+
+ if (!config->num_available_pcs)
+ return 0;
+
+ if (!config->fill_available_pcs) {
+ dev_err(config->dev,
+ "phylink: error: num_available_pcs defined but no fill_available_pcs\n");
+ return -EINVAL;
+ }
+
+ pcss = kzalloc_objs(*pcss, config->num_available_pcs);
+ if (!pcss)
+ return -ENOMEM;
+
+ ret = config->fill_available_pcs(config, pcss, config->num_available_pcs);
+ if (ret)
+ goto out;
+
+ for (i = 0; i < config->num_available_pcs; i++) {
+ struct phylink_pcs *pcs = pcss[i];
+
+ if (!pcs)
+ continue;
+
+ list_add(&pcs->list, &pl->pcs_list);
+ }
+
+out:
+ kfree(pcss);
+
+ return ret;
+}
+
/**
* phylink_create() - create a phylink instance
* @config: a pointer to the target &struct phylink_config
@@ -1855,6 +1970,7 @@ struct phylink *phylink_create(struct phylink_config *config,
phy_interface_t iface,
const struct phylink_mac_ops *mac_ops)
{
+ struct phylink_pcs *pcs;
struct phylink *pl;
int ret;
@@ -1872,9 +1988,21 @@ struct phylink *phylink_create(struct phylink_config *config,
mutex_init(&pl->phydev_mutex);
mutex_init(&pl->state_mutex);
INIT_WORK(&pl->resolve, phylink_resolve);
+ INIT_LIST_HEAD(&pl->pcs_list);
+
+ /* Fill the PCS list with available PCS from phylink config */
+ ret = phylink_fill_available_pcs(pl, config);
+ if (ret) {
+ kfree(pl);
+ return ERR_PTR(ret);
+ }
phy_interface_copy(pl->supported_interfaces,
config->supported_interfaces);
+ list_for_each_entry(pcs, &pl->pcs_list, list)
+ phy_interface_or(pl->supported_interfaces,
+ pl->supported_interfaces,
+ pcs->supported_interfaces);
pl->config = config;
if (config->type == PHYLINK_NETDEV) {
@@ -1953,10 +2081,16 @@ EXPORT_SYMBOL_GPL(phylink_create);
*/
void phylink_destroy(struct phylink *pl)
{
+ struct phylink_pcs *pcs, *tmp;
+
sfp_bus_del_upstream(pl->sfp_bus);
if (pl->link_gpio)
gpiod_put(pl->link_gpio);
+ /* Remove every PCS from phylink PCS list */
+ list_for_each_entry_safe(pcs, tmp, &pl->pcs_list, list)
+ list_del(&pcs->list);
+
cancel_work_sync(&pl->resolve);
kfree(pl);
}
@@ -2437,6 +2571,7 @@ static irqreturn_t phylink_link_handler(int irq, void *data)
*/
void phylink_start(struct phylink *pl)
{
+ struct phylink_pcs *pcs;
bool poll = false;
ASSERT_RTNL();
@@ -2463,6 +2598,10 @@ void phylink_start(struct phylink *pl)
pl->pcs_state = PCS_STATE_STARTED;
+ /* link available PCS to phylink struct */
+ list_for_each_entry(pcs, &pl->pcs_list, list)
+ pcs->phylink = pl;
+
phylink_enable_and_run_resolve(pl, PHYLINK_DISABLE_STOPPED);
if (pl->cfg_link_an_mode == MLO_AN_FIXED && pl->link_gpio) {
@@ -2507,6 +2646,8 @@ EXPORT_SYMBOL_GPL(phylink_start);
*/
void phylink_stop(struct phylink *pl)
{
+ struct phylink_pcs *pcs;
+
ASSERT_RTNL();
if (pl->sfp_bus)
@@ -2524,6 +2665,14 @@ void phylink_stop(struct phylink *pl)
pl->pcs_state = PCS_STATE_DOWN;
phylink_pcs_disable(pl->pcs);
+
+ /* Drop link between phylink and PCS */
+ list_for_each_entry(pcs, &pl->pcs_list, list)
+ pcs->phylink = NULL;
+
+ /* Restore original supported interfaces */
+ phy_interface_copy(pl->supported_interfaces,
+ pl->config->supported_interfaces);
}
EXPORT_SYMBOL_GPL(phylink_stop);
diff --git a/include/linux/phylink.h b/include/linux/phylink.h
index 2bc0db3d52ac..3387d308c4ad 100644
--- a/include/linux/phylink.h
+++ b/include/linux/phylink.h
@@ -12,6 +12,7 @@ struct ethtool_cmd;
struct fwnode_handle;
struct net_device;
struct phylink;
+struct phylink_pcs;
enum {
MLO_PAUSE_NONE,
@@ -151,6 +152,8 @@ enum phylink_op_type {
* if MAC link is at %MLO_AN_FIXED mode.
* @supported_interfaces: bitmap describing which PHY_INTERFACE_MODE_xxx
* are supported by the MAC/PCS.
+ * @pcs_interfaces: bitmap describing for which PHY_INTERFACE_MODE_xxx a
+ * dedicated PCS is required.
* @lpi_interfaces: bitmap describing which PHY interface modes can support
* LPI signalling.
* @mac_capabilities: MAC pause/speed/duplex capabilities.
@@ -160,6 +163,10 @@ enum phylink_op_type {
* @wol_phy_legacy: Use Wake-on-Lan with PHY even if phy_can_wakeup() is false
* @wol_phy_speed_ctrl: Use phy speed control on suspend/resume
* @wol_mac_support: Bitmask of MAC supported %WAKE_* options
+ * @num_available_pcs: num of available phylink_pcs PCS
+ * @fill_available_pcs: callback to fill the available PCS in the passed
+ * array struct of phylink_pcs PCS available_pcs up to
+ * num_available_pcs.
*/
struct phylink_config {
struct device *dev;
@@ -172,6 +179,7 @@ struct phylink_config {
void (*get_fixed_state)(struct phylink_config *config,
struct phylink_link_state *state);
DECLARE_PHY_INTERFACE_MASK(supported_interfaces);
+ DECLARE_PHY_INTERFACE_MASK(pcs_interfaces);
DECLARE_PHY_INTERFACE_MASK(lpi_interfaces);
unsigned long mac_capabilities;
unsigned long lpi_capabilities;
@@ -182,6 +190,11 @@ struct phylink_config {
bool wol_phy_legacy;
bool wol_phy_speed_ctrl;
u32 wol_mac_support;
+
+ unsigned int num_available_pcs;
+ int (*fill_available_pcs)(struct phylink_config *config,
+ struct phylink_pcs **available_pcs,
+ unsigned int num_available_pcs);
};
void phylink_limit_mac_speed(struct phylink_config *config, u32 max_speed);
@@ -497,6 +510,9 @@ struct phylink_pcs {
struct phylink *phylink;
bool poll;
bool rxc_always_on;
+
+ /* private: */
+ struct list_head list;
};
/**
--
2.53.0
^ permalink raw reply related
* [PATCH v2 5/7] clk: qcom: Add defaults for desired arm64 drivers
From: Krzysztof Kozlowski @ 2026-06-09 15:32 UTC (permalink / raw)
To: Bjorn Andersson, Michael Turquette, Stephen Boyd, Brian Masney,
Konrad Dybcio
Cc: linux-arm-msm, linux-clk, linux-kernel, linux-arm-kernel,
Krzysztof Kozlowski
In-Reply-To: <20260609-clk-qcom-defaults-v2-0-0c67c06dca11@oss.qualcomm.com>
Clock controller drivers are essential for booting up SoCs and are not
really optional for a given platform. Kernel should not ask users
choice of drivers when that choice is obvious and known to the
developers that answer should be 'yes' or 'module'.
Enable drivers for upstreamed or being upstreamed SoCs, which are not
yed enabled in defconfig: Glymur, Hawi, Nord, MSM8976, MSM8998 (GPU CC),
SC7180, SC8180X, SC8280XP, SC7280, SDM660, QDU1000, SM4450, SM7150,
SM8150, SM8450, SM6125, SM6375. Note that main GCC clock controller
drivers are usually already enabled for these.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
Changes in v2:
1. Add defaults for: MSM_GCC_8976, MSM_GPUCC_8998, SDM_GCC_660,
SDM_MMCC_660, SDM_GPUCC_660, HAWI
2. Drop the Konrad RB tag, considering above a significant change.
---
drivers/clk/qcom/Kconfig | 36 ++++++++++++++++++++++++++++++++++++
1 file changed, 36 insertions(+)
diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
index ed969553649c..9afd4d752f3a 100644
--- a/drivers/clk/qcom/Kconfig
+++ b/drivers/clk/qcom/Kconfig
@@ -73,6 +73,7 @@ config CLK_GLYMUR_GPUCC
tristate "GLYMUR Graphics Clock Controller"
depends on ARM64 || COMPILE_TEST
select CLK_GLYMUR_GCC
+ default m if ARCH_QCOM
help
Support for the graphics clock controller on GLYMUR devices.
Say Y if you want to support graphics controller devices and
@@ -91,6 +92,7 @@ config CLK_GLYMUR_VIDEOCC
tristate "Glymur Video Clock Controller"
depends on ARM64 || COMPILE_TEST
select CLK_GLYMUR_GCC
+ default m if ARCH_QCOM
help
Support for the video clock controller on Glymur devices.
Say Y if you want to support video devices and functionality such as
@@ -161,6 +163,7 @@ config CLK_NORD_GCC
tristate "Nord Global Clock Controller"
depends on ARM64 || COMPILE_TEST
select QCOM_GDSC
+ default ARCH_QCOM
help
Support for the global clock controller on Nord devices.
Say Y if you want to use peripheral devices such as UART,
@@ -328,6 +331,7 @@ config CLK_HAWI_GCC
tristate "Hawi Global Clock Controller"
depends on ARM64 || COMPILE_TEST
select QCOM_GDSC
+ default ARCH_QCOM
help
Support for the global clock controller on Hawi devices.
Say Y if you want to use peripheral devices such as UART, SPI,
@@ -336,6 +340,7 @@ config CLK_HAWI_GCC
config CLK_HAWI_TCSRCC
tristate "Hawi TCSR Clock Controller"
depends on ARM64 || COMPILE_TEST
+ default m if ARCH_QCOM
help
Support for the TCSR clock controller on Hawi devices.
Say Y if you want to use peripheral devices such as PCIe, USB, UFS.
@@ -661,6 +666,7 @@ config MSM_MMCC_8974
config MSM_GCC_8976
tristate "MSM8956/76 Global Clock Controller"
select QCOM_GDSC
+ default ARCH_QCOM if ARM64
help
Support for the global clock controller on msm8956/76 devices.
Say Y if you want to use peripheral devices such as UART, SPI,
@@ -716,6 +722,7 @@ config MSM_GPUCC_8998
tristate "MSM8998 Graphics Clock Controller"
select MSM_GCC_8998
select QCOM_GDSC
+ default m if ARCH_QCOM && ARM64
help
Support for the graphics clock controller on MSM8998 devices.
Say Y if you want to support graphics controller devices and
@@ -785,6 +792,7 @@ config QCS_GCC_404
config CLK_NORD_TCSRCC
tristate "Nord TCSR Clock Controller"
depends on ARM64 || COMPILE_TEST
+ default m if ARCH_QCOM
help
Support for the TCSR clock controller on Nord devices.
Say Y if you want to use peripheral devices such as PCIe, USB, UFS etc.
@@ -845,6 +853,7 @@ config SC_CAMCC_7180
tristate "SC7180 Camera Clock Controller"
depends on ARM64 || COMPILE_TEST
select SC_GCC_7180
+ default m if ARCH_QCOM
help
Support for the camera clock controller on Qualcomm Technologies, Inc
SC7180 devices.
@@ -866,6 +875,7 @@ config SC_CAMCC_8180X
tristate "SC8180X Camera Clock Controller"
depends on ARM64 || COMPILE_TEST
select SC_GCC_8180X
+ default m if ARCH_QCOM
help
Support for the camera clock controller on Qualcomm Technologies, Inc
SC8180X devices.
@@ -898,6 +908,7 @@ config SC_DISPCC_7180
tristate "SC7180 Display Clock Controller"
depends on ARM64 || COMPILE_TEST
select SC_GCC_7180
+ default m if ARCH_QCOM
help
Support for the display clock controller on Qualcomm Technologies, Inc
SC7180 devices.
@@ -1014,6 +1025,7 @@ config SC_GPUCC_7180
tristate "SC7180 Graphics Clock Controller"
depends on ARM64 || COMPILE_TEST
select SC_GCC_7180
+ default m if ARCH_QCOM
help
Support for the graphics clock controller on SC7180 devices.
Say Y if you want to support graphics controller devices and
@@ -1043,6 +1055,7 @@ config SC_LPASSCC_7280
tristate "SC7280 Low Power Audio Subsystem (LPASS) Clock Controller"
depends on ARM64 || COMPILE_TEST
select SC_GCC_7280
+ default m if ARCH_QCOM
help
Support for the LPASS clock controller on SC7280 devices.
Say Y if you want to use the LPASS branch clocks of the LPASS clock
@@ -1084,6 +1097,7 @@ config SC_VIDEOCC_7180
tristate "SC7180 Video Clock Controller"
depends on ARM64 || COMPILE_TEST
select SC_GCC_7180
+ default m if ARCH_QCOM
help
Support for the video clock controller on SC7180 devices.
Say Y if you want to support video devices and functionality such as
@@ -1112,6 +1126,7 @@ config SDM_GCC_660
tristate "SDM660 Global Clock Controller"
depends on ARM64 || COMPILE_TEST
select QCOM_GDSC
+ default m if ARCH_QCOM
help
Support for the global clock controller on SDM660 devices.
Say Y if you want to use peripheral devices such as UART, SPI,
@@ -1122,6 +1137,7 @@ config SDM_MMCC_660
depends on ARM64 || COMPILE_TEST
select SDM_GCC_660
select QCOM_GDSC
+ default m if ARCH_QCOM
help
Support for the multimedia clock controller on SDM660 devices.
Say Y if you want to support multimedia devices such as display,
@@ -1132,6 +1148,7 @@ config SDM_GPUCC_660
depends on ARM64 || COMPILE_TEST
select SDM_GCC_660
select QCOM_GDSC
+ default m if ARCH_QCOM
help
Support for the graphics clock controller on SDM630/636/660 devices.
Say Y if you want to support graphics controller devices and
@@ -1165,6 +1182,7 @@ config QDU_ECPRICC_1000
tristate "QDU1000/QRU1000 ECPRI Clock Controller"
depends on ARM64 || COMPILE_TEST
select QDU_GCC_1000
+ default m if ARCH_QCOM
help
Support for the ECPRI clock controller on QDU1000 and
QRU1000 devices. Say Y if you want to support the ECPRI
@@ -1254,6 +1272,7 @@ config SM_CAMCC_4450
tristate "SM4450 Camera Clock Controller"
depends on ARM64 || COMPILE_TEST
select SM_GCC_4450
+ default m if ARCH_QCOM
help
Support for the camera clock controller on SM4450 devices.
Say Y if you want to support camera devices and camera functionality.
@@ -1271,6 +1290,7 @@ config SM_CAMCC_7150
tristate "SM7150 Camera Clock Controller"
depends on ARM64 || COMPILE_TEST
select SM_GCC_7150
+ default m if ARCH_QCOM
help
Support for the camera clock controller on SM7150 devices.
Say Y if you want to support camera devices and camera functionality.
@@ -1288,6 +1308,7 @@ config SM_CAMCC_8150
tristate "SM8150 Camera Clock Controller"
depends on ARM64 || COMPILE_TEST
select SM_GCC_8150
+ default m if ARCH_QCOM
help
Support for the camera clock controller on Qualcomm Technologies, Inc
SM8150 devices.
@@ -1307,6 +1328,7 @@ config SM_CAMCC_8450
tristate "SM8450 Camera Clock Controller"
depends on ARM64 || COMPILE_TEST
select SM_GCC_8450
+ default m if ARCH_QCOM
help
Support for the camera clock controller on SM8450 or SM8475 devices.
Say Y if you want to support camera devices and camera functionality.
@@ -1344,6 +1366,7 @@ config SM_DISPCC_4450
tristate "SM4450 Display Clock Controller"
depends on ARM64 || COMPILE_TEST
depends on SM_GCC_4450
+ default m if ARCH_QCOM
help
Support for the display clock controller on Qualcomm Technologies, Inc
SM4450 devices.
@@ -1365,6 +1388,7 @@ config SM_DISPCC_6125
tristate "SM6125 Display Clock Controller"
depends on ARM64 || COMPILE_TEST
depends on SM_GCC_6125
+ default m if ARCH_QCOM
help
Support for the display clock controller on Qualcomm Technologies, Inc
SM6125 devices.
@@ -1375,6 +1399,7 @@ config SM_DISPCC_7150
tristate "SM7150 Display Clock Controller"
depends on ARM64 || COMPILE_TEST
depends on SM_GCC_7150
+ default m if ARCH_QCOM
help
Support for the display clock controller on Qualcomm Technologies, Inc
SM7150 devices.
@@ -1407,6 +1432,7 @@ config SM_DISPCC_6375
tristate "SM6375 Display Clock Controller"
depends on ARM64 || COMPILE_TEST
depends on SM_GCC_6375
+ default m if ARCH_QCOM
help
Support for the display clock controller on Qualcomm Technologies, Inc
SM6375 devices.
@@ -1482,6 +1508,7 @@ config SM_GCC_6125
tristate "SM6125 Global Clock Controller"
depends on ARM64 || COMPILE_TEST
select QCOM_GDSC
+ default ARCH_QCOM
help
Support for the global clock controller on SM6125 devices.
Say Y if you want to use peripheral devices such as UART,
@@ -1501,6 +1528,7 @@ config SM_GCC_6375
tristate "SM6375 Global Clock Controller"
depends on ARM64 || COMPILE_TEST
select QCOM_GDSC
+ default ARCH_QCOM
help
Support for the global clock controller on SM6375 devices.
Say Y if you want to use peripheral devices such as UART,
@@ -1510,6 +1538,7 @@ config SM_GCC_7150
tristate "SM7150 Global Clock Controller"
depends on ARM64 || COMPILE_TEST
select QCOM_GDSC
+ default ARCH_QCOM
help
Support for the global clock controller on SM7150 devices.
Say Y if you want to use peripheral devices such as UART,
@@ -1600,6 +1629,7 @@ config SM_GPUCC_4450
tristate "SM4450 Graphics Clock Controller"
depends on ARM64 || COMPILE_TEST
select SM_GCC_4450
+ default m if ARCH_QCOM
help
Support for the graphics clock controller on SM4450 devices.
Say Y if you want to support graphics controller devices and
@@ -1619,6 +1649,7 @@ config SM_GPUCC_6125
tristate "SM6125 Graphics Clock Controller"
select SM_GCC_6125
depends on ARM64 || COMPILE_TEST
+ default m if ARCH_QCOM
help
Support for the graphics clock controller on SM6125 devices.
Say Y if you want to support graphics controller devices and
@@ -1628,6 +1659,7 @@ config SM_GPUCC_6375
tristate "SM6375 Graphics Clock Controller"
select SM_GCC_6375
depends on ARM64 || COMPILE_TEST
+ default m if ARCH_QCOM
help
Support for the graphics clock controller on SM6375 devices.
Say Y if you want to support graphics controller devices and
@@ -1728,6 +1760,7 @@ config SM_LPASSCC_6115
tristate "SM6115 Low Power Audio Subsystem (LPASS) Clock Controller"
depends on ARM64 || COMPILE_TEST
select SM_GCC_6115
+ default m if ARCH_QCOM
help
Support for the LPASS clock controller on SM6115 devices.
Say Y if you want to toggle LPASS-adjacent resets within
@@ -1788,6 +1821,7 @@ config SM_VIDEOCC_7150
depends on ARM64 || COMPILE_TEST
select SM_GCC_7150
select QCOM_GDSC
+ default m if ARCH_QCOM
help
Support for the video clock controller on SM7150 devices.
Say Y if you want to support video devices and functionality such as
@@ -1810,6 +1844,7 @@ config SM_VIDEOCC_8150
depends on ARM64 || COMPILE_TEST
select SM_GCC_8150
select QCOM_GDSC
+ default m if ARCH_QCOM
help
Support for the video clock controller on SM8150 devices.
Say Y if you want to support video devices and functionality such as
@@ -1831,6 +1866,7 @@ config SM_VIDEOCC_8350
depends on ARM64 || COMPILE_TEST
depends on SM_GCC_8350 || SC_GCC_8280XP
select QCOM_GDSC
+ default m if ARCH_QCOM
help
Support for the video clock controller on SM8350 or SC8280XP devices.
Say Y if you want to support video devices and functionality such as
--
2.53.0
^ permalink raw reply related
* Re: [PATCH] PCI: meson: Propagate devm_add_action_or_reset() failure
From: Manivannan Sadhasivam @ 2026-06-09 16:25 UTC (permalink / raw)
To: Yue Wang, Lorenzo Pieralisi, Rob Herring, Bjorn Helgaas,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Shuvam Pandey
Cc: linux-pci, linux-amlogic, linux-arm-kernel, linux-kernel
In-Reply-To: <177909148011.9588.6639767953842842291@gmail.com>
On Mon, 18 May 2026 13:49:40 +0545, Shuvam Pandey wrote:
> meson_pcie_probe_clock() enables a clock and then registers a devres
> action to disable it during teardown. If devm_add_action_or_reset()
> fails, it runs the action immediately, disabling the clock.
>
> The return value is currently ignored, so on that failure path
> meson_pcie_probe_clock() returns the disabled clock and probe continues.
> Return the error so the existing probe error path unwinds normally.
>
> [...]
Applied, thanks!
[1/1] PCI: meson: Propagate devm_add_action_or_reset() failure
commit: b12341b98d5ac52f48ca1390e1e371aed81346c8
Best regards,
--
Manivannan Sadhasivam <mani@kernel.org>
^ permalink raw reply
* Re: [PATCH v3 2/3] dt-bindings: mfd: syscon: Drop custom select for older dtschema
From: Conor Dooley @ 2026-06-09 16:28 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, Jacky Huang,
Shan-Chun Hung, Geert Uytterhoeven, Magnus Damm, Heiko Stuebner,
Aaro Koskinen, Andreas Kemnade, Kevin Hilman, Roger Quadros,
Tony Lindgren, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, linux-renesas-soc, linux-rockchip, linux-omap
In-Reply-To: <20260608-n-dt-bindings-simple-bus-syscon-v3-2-4eba9ec1212a@oss.qualcomm.com>
[-- Attachment #1: Type: text/plain, Size: 6856 bytes --]
On Mon, Jun 08, 2026 at 10:44:25PM +0200, Krzysztof Kozlowski wrote:
> Older dtschema <2024.02 required custom select to avoid applying this
> binding to anything having "syscon" compatible. That's not the case
> anymore and this additional select has two headaches:
>
> 1. Duplicates all the compatibles listed in the schema.
>
> 2. Is error-prone, because it requires contributor to add the compatible
> in two places, otherwise the schema will be silently ignored.
> The select list already misses mentioning compatibles:
> mediatek,mt8365-infracfg-nao and renesas,r9a08g046-lvds-cmn (with the
> latter being reverted for different reasons).
>
> This requires bumping minimum dtschema requirement to v2024.04, which
> feels old enough to be a safe requirement.
I agree, seems reasonable enough given it's a jump from 2023.09 and not
some large jump.
The diff is nice too!
I assume Rob will be taking it, but just in case..
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Cheers,
Conor.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>
> ---
>
> Changes in v3:
> 1. Bump dtschema requirement
>
> Changes in v2:
> 1. New patch
> ---
> Documentation/devicetree/bindings/Makefile | 2 +-
> Documentation/devicetree/bindings/mfd/syscon.yaml | 116 ----------------------
> 2 files changed, 1 insertion(+), 117 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/Makefile b/Documentation/devicetree/bindings/Makefile
> index 7b668f7fd400..40c2094f47c2 100644
> --- a/Documentation/devicetree/bindings/Makefile
> +++ b/Documentation/devicetree/bindings/Makefile
> @@ -6,7 +6,7 @@ DT_MK_SCHEMA ?= dt-mk-schema
> DT_SCHEMA_LINT = $(shell which yamllint || \
> echo "warning: python package 'yamllint' not installed, skipping" >&2)
>
> -DT_SCHEMA_MIN_VERSION = 2023.9
> +DT_SCHEMA_MIN_VERSION = 2024.4
>
> PHONY += check_dtschema_version
> check_dtschema_version:
> diff --git a/Documentation/devicetree/bindings/mfd/syscon.yaml b/Documentation/devicetree/bindings/mfd/syscon.yaml
> index 9c81010d5a74..b70018bf1bcf 100644
> --- a/Documentation/devicetree/bindings/mfd/syscon.yaml
> +++ b/Documentation/devicetree/bindings/mfd/syscon.yaml
> @@ -19,122 +19,6 @@ description: |
> maintainers:
> - Lee Jones <lee@kernel.org>
>
> -# Need a select with all compatibles listed for compatibility with older
> -# dtschema (<2024.02), so this will not be selected for other schemas having
> -# syscon fallback.
> -select:
> - properties:
> - compatible:
> - contains:
> - enum:
> - - airoha,en7581-pbus-csr
> - - al,alpine-sysfabric-service
> - - allwinner,sun8i-a83t-system-controller
> - - allwinner,sun8i-h3-system-controller
> - - allwinner,sun8i-v3s-system-controller
> - - allwinner,sun50i-a64-system-controller
> - - altr,l3regs
> - - altr,sdr-ctl
> - - amd,pensando-elba-syscon
> - - amlogic,meson-mx-assist
> - - amlogic,meson-mx-bootrom
> - - amlogic,meson8-analog-top
> - - amlogic,meson8b-analog-top
> - - amlogic,meson8-pmu
> - - amlogic,meson8b-pmu
> - - apm,merlin-poweroff-mailbox
> - - apm,mustang-poweroff-mailbox
> - - apm,xgene-csw
> - - apm,xgene-efuse
> - - apm,xgene-mcb
> - - apm,xgene-rb
> - - apm,xgene-scu
> - - atmel,sama5d2-sfrbu
> - - atmel,sama5d3-nfc-io
> - - atmel,sama5d3-sfrbu
> - - atmel,sama5d4-sfrbu
> - - axis,artpec6-syscon
> - - brcm,cru-clkset
> - - brcm,sr-cdru
> - - brcm,sr-mhb
> - - cirrus,ep7209-syscon1
> - - cirrus,ep7209-syscon2
> - - cirrus,ep7209-syscon3
> - - cnxt,cx92755-uc
> - - econet,en751221-chip-scu
> - - freecom,fsg-cs2-system-controller
> - - fsl,imx93-aonmix-ns-syscfg
> - - fsl,imx93-wakeupmix-syscfg
> - - fsl,ls1088a-reset
> - - fsl,vf610-anatop
> - - fsl,vf610-mscm-cpucfg
> - - hisilicon,dsa-subctrl
> - - hisilicon,hi6220-sramctrl
> - - hisilicon,hip04-ppe
> - - hisilicon,pcie-sas-subctrl
> - - hisilicon,peri-subctrl
> - - hpe,gxp-sysreg
> - - loongson,ls1b-syscon
> - - loongson,ls1c-syscon
> - - lsi,axxia-syscon
> - - marvell,armada-3700-cpu-misc
> - - marvell,armada-3700-nb-pm
> - - marvell,armada-3700-avs
> - - marvell,armada-3700-usb2-host-device-misc
> - - marvell,armada-3700-usb2-host-misc
> - - marvell,dove-global-config
> - - mediatek,mt2701-pctl-a-syscfg
> - - mediatek,mt2712-pctl-a-syscfg
> - - mediatek,mt6397-pctl-pmic-syscfg
> - - mediatek,mt7981-topmisc
> - - mediatek,mt7988-topmisc
> - - mediatek,mt8135-pctl-a-syscfg
> - - mediatek,mt8135-pctl-b-syscfg
> - - mediatek,mt8173-pctl-a-syscfg
> - - mediatek,mt8365-syscfg
> - - microchip,lan966x-cpu-syscon
> - - microchip,mpfs-control-scb
> - - microchip,mpfs-sysreg-scb
> - - microchip,sam9x60-sfr
> - - microchip,sama7d65-ddr3phy
> - - microchip,sama7d65-sfrbu
> - - microchip,sama7g5-ddr3phy
> - - mscc,ocelot-cpu-syscon
> - - mstar,msc313-pmsleep
> - - nuvoton,ma35d1-sys
> - - nuvoton,wpcm450-shm
> - - nxp,s32g2-gpr
> - - nxp,s32g3-gpr
> - - qcom,apq8064-mmss-sfpb
> - - qcom,apq8064-sps-sic
> - - rockchip,px30-qos
> - - rockchip,rk3036-qos
> - - rockchip,rk3066-qos
> - - rockchip,rk3128-qos
> - - rockchip,rk3228-qos
> - - rockchip,rk3288-qos
> - - rockchip,rk3368-qos
> - - rockchip,rk3399-qos
> - - rockchip,rk3528-qos
> - - rockchip,rk3562-qos
> - - rockchip,rk3568-qos
> - - rockchip,rk3576-qos
> - - rockchip,rk3588-qos
> - - rockchip,rv1126-qos
> - - st,spear1340-misc
> - - stericsson,nomadik-pmu
> - - starfive,jh7100-sysmain
> - - ti,am62-opp-efuse-table
> - - ti,am62-usb-phy-ctrl
> - - ti,am625-dss-oldi-io-ctrl
> - - ti,am62p-cpsw-mac-efuse
> - - ti,am654-dss-oldi-io-ctrl
> - - ti,j784s4-acspcie-proxy-ctrl
> - - ti,j784s4-pcie-ctrl
> - - ti,keystone-pllctrl
> - required:
> - - compatible
> -
> properties:
> compatible:
> oneOf:
>
> --
> 2.53.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] KVM: arm64: Replace memslot_is_logging() with kvm_slot_dirty_track_enabled()
From: Leonardo Bras @ 2026-06-09 16:31 UTC (permalink / raw)
To: Wei-Lin Chang
Cc: Leonardo Bras, linux-arm-kernel, kvmarm, linux-kernel,
Marc Zyngier, Oliver Upton, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon,
Gavin Shan
In-Reply-To: <aibmALTEbc7gzSZj@devkitleo>
On Mon, Jun 08, 2026 at 04:55:45PM +0100, Leonardo Bras wrote:
> Hi Wei Lin,
>
> On Fri, Jun 05, 2026 at 04:32:47PM +0100, Wei-Lin Chang wrote:
> > When checking whether a memslot has dirty logging enabled, the
> > KVM_MEM_LOG_DIRTY_PAGES flag is the source of truth. Previously we were
> > using memslot_is_logging() which only tests dirty bitmap and did not
> > consider dirty ring. This was not detected because
> > KVM_CAP_DIRTY_LOG_RING_WITH_BITMAP was introduced together with KVM
> > arm64 dirty ring, and users need to enable it to ensure dirty
> > information is not lost for the case of VGIC LPI/ITS table changes.
> >
> > Fix this by using kvm_slot_dirty_track_enabled() instead which checks
> > KVM_MEM_LOG_DIRTY_PAGES.
> >
> > Note that memslot_is_logging() also treats a memslot as not logging if
> > KVM_MEM_READONLY is set, hence a memslot with both dirty logging and
> > read only would be seen as not logging for memslot_is_logging(), but
> > logging for kvm_slot_dirty_track_enabled(). This allows a read only
> > mapping of size > PAGE_SIZE to be built when memslot_is_logging() is
> > used, leading to a better read performance compared to
> > kvm_slot_dirty_track_enabled(). However memslots that have both
> > KVM_MEM_LOG_DIRTY_PAGES and KVM_MEM_READONLY set do not really make
> > sense as dirty logging is essentially nop for a read only memslot, so
> > this shouldn't affect real workloads much.
>
>
> It worries me a bit that we are ignoring the KVM_MEM_READONLY flag...
> I have not yet gone through the whole s2_mmu code but IIUC we can have
> scenarios on which a memslot can be read-only and have dirty-logging
> enabled.
> If a memslot is not faulted yet, IIUC it is marked as read-only
> (so it can be mapped on write fault), and we can have dirty-logging
> enabled for it as well (as the VMM has no idea).
>
Ignore above bit, I confused memslot with block/page entry.
Looking a bit more, my viewpoint is that:
- Due to dirty_ring, checking memslot.dirty_bitmap should be done only to
detect the existence of a dirty_bitmap, not the migration process.
- This changes how detection works, in regardas to read-only blocks:
memslot_is_logging() -> Checks dirty-bitmap + read-only memslot
kvm_slot_dirty_track_enabled() -> Checks only memslot flag
- As a simpler change, we could have:
~~~
- return memslot->dirty_bitmap && !(memslot->flags & KVM_MEM_READONLY);
+ return kvm_slot_dirty_track_enabled(memslot) && !(memslot->flags & KVM_MEM_READONLY);
~~~
Both are cheking memslot->flags, so it will be probably optimized by the
compiler as:
~~~
return memslot->flags & 3 == 1
~~~
My main worry was that in the curent patch we are changing the behavior
on skipping read-only memslots. So going through the users, we can see:
> >
> > Fixes: 9cb1096f8590 ("KVM: arm64: Enable ring-based dirty memory tracking")
> > Signed-off-by: Wei-Lin Chang <weilin.chang@arm.com>
> > ---
> > It took me a long investigation to acquire the context needed to
> > understand this change, however the reason for this problem not being
> > detected is an educated guess. Please let me know if this is wrong or
> > if there are other issues, thanks!
> >
> > arch/arm64/kvm/mmu.c | 11 +++--------
> > 1 file changed, 3 insertions(+), 8 deletions(-)
> >
> > diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> > index 4da9281312eb..06c46124d3e7 100644
> > --- a/arch/arm64/kvm/mmu.c
> > +++ b/arch/arm64/kvm/mmu.c
> > @@ -161,11 +161,6 @@ static int kvm_mmu_split_huge_pages(struct kvm *kvm, phys_addr_t addr,
> > return ret;
> > }
> >
> > -static bool memslot_is_logging(struct kvm_memory_slot *memslot)
> > -{
> > - return memslot->dirty_bitmap && !(memslot->flags & KVM_MEM_READONLY);
> > -}
> > -
> > /**
> > * kvm_arch_flush_remote_tlbs() - flush all VM TLB entries for v7/8
> > * @kvm: pointer to kvm structure.
> > @@ -1748,7 +1743,7 @@ static short kvm_s2_resolve_vma_size(const struct kvm_s2_fault_desc *s2fd,
> > {
> > short vma_shift;
> >
> > - if (memslot_is_logging(s2fd->memslot)) {
> > + if (kvm_slot_dirty_track_enabled(s2fd->memslot)) {
> > s2vi->max_map_size = PAGE_SIZE;
> > vma_shift = PAGE_SHIFT;
> > } else {
On the case dirty_track is enabled in a read-only slot, it will resolve to
a smaller vma_size. The fault granule will be smaller here. This could be
bad for performance, so maybe we could add a check for read-only block
here:
~~~
- if (memslot_is_logging(s2fd->memslot)) {
+ if (kvm_slot_dirty_track_enabled(s2fd->memslot) &&
+ !memslot_is_readonly(s2fd->memslot) {
~~~
> > @@ -1953,7 +1948,7 @@ static int kvm_s2_fault_compute_prot(const struct kvm_s2_fault_desc *s2fd,
> > *prot = KVM_PGTABLE_PROT_R;
> >
> > if (s2vi->map_writable && (s2vi->device ||
> > - !memslot_is_logging(s2fd->memslot) ||
> > + !kvm_slot_dirty_track_enabled(s2fd->memslot) ||
> > kvm_is_write_fault(s2fd->vcpu)))
> > *prot |= KVM_PGTABLE_PROT_W;
> >
On the same scenario (dirty_track enabled on readonly memslot):
This one should be safe, as kvm_is_write_fault() will check if the memslot
is readonly and return false in this case. But then, it will have to
actually call kvm_is_write_fault(), as the previous version would not even
call it in that scenario.
Not sure how would that impact perforformance, though.
> > @@ -2084,7 +2079,7 @@ static int user_mem_abort(const struct kvm_s2_fault_desc *s2fd)
> > * and a write fault needs to collapse a block entry into a table.
> > */
> > memcache = get_mmu_memcache(s2fd->vcpu);
> > - if (!perm_fault || (memslot_is_logging(s2fd->memslot) &&
> > + if (!perm_fault || (kvm_slot_dirty_track_enabled(s2fd->memslot) &&
> > kvm_is_write_fault(s2fd->vcpu))) {
> > ret = topup_mmu_memcache(s2fd->vcpu, memcache);
> > if (ret)
Same thing, if memslot is tracking and is readonly, topup_*() would be
called with the new patch, but not with the old behavior.
All of that depends on how the VMM uses dirty_tracking: does it enable for
all memory, or only for memory that is writable?
I could not find anything that would prevent user from enabling
dirty_tracking on read-only memslots, so we can either ignore this
scenario, apply those patches and let those users carry the extra overhead,
or do an extra test to make sure it's doing the same thing as before.
Thanks!
Leo
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: usb: Add Rockchip RK3568 compatible for EHCI and OHCI
From: Diederik de Haas @ 2026-06-09 16:32 UTC (permalink / raw)
To: Jonas Karlman, Heiko Stuebner, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Greg Kroah-Hartman
Cc: Diederik de Haas, devicetree, linux-rockchip, linux-usb,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260609154124.445182-2-jonas@kwiboo.se>
Hi Jonas,
On Tue Jun 9, 2026 at 5:41 PM CEST, Jonas Karlman wrote:
> The Rockchip RK3568 EHCI/OHCI controller depends on clk_usbphy1_480m
> being enabled, or the system may freeze when registers are accessed.
>
> Add Rockchip RK3568 EHCI and OHCI compatibles with a similar four-clock
> constraint as RK3588.
>
> Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
> ---
> Existing DTs for RK3568 use the plain generic-ehci/ohci compatible,
> next patch make use of these new compatibles and adds the missing
> clk_usbphy1_480m clock references.
> ---
> .../devicetree/bindings/usb/generic-ehci.yaml | 10 ++++++++++
> .../devicetree/bindings/usb/generic-ohci.yaml | 5 ++++-
> 2 files changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/usb/generic-ehci.yaml b/Documentation/devicetree/bindings/usb/generic-ehci.yaml
> index 55a5aa7d7a54..c49a1bbc8cfd 100644
> --- a/Documentation/devicetree/bindings/usb/generic-ehci.yaml
> +++ b/Documentation/devicetree/bindings/usb/generic-ehci.yaml
> @@ -52,6 +52,7 @@ properties:
> - ibm,476gtr-ehci
> - nxp,lpc1850-ehci
> - qca,ar7100-ehci
> + - rockchip,rk3568-ehci
> - rockchip,rk3588-ehci
> - snps,hsdk-v1.0-ehci
> - socionext,uniphier-ehci
> @@ -186,6 +187,15 @@ allOf:
> required:
> - clocks
> - clock-names
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: rockchip,rk3568-ehci
> + then:
> + properties:
> + clocks:
> + minItems: 4
I think that the constraint for rk3588 is this:
- minItems: 1
- maxItems: 4
Like ~ every other compatible; there's no 'branch' for rk3588-ehci.
That's different from what you add for rk3568. Is that deliberate?
Because from the commit message I assumed they should be the same.
> unevaluatedProperties: false
>
> diff --git a/Documentation/devicetree/bindings/usb/generic-ohci.yaml b/Documentation/devicetree/bindings/usb/generic-ohci.yaml
> index d42f448fa204..5f1b4d2bff89 100644
> --- a/Documentation/devicetree/bindings/usb/generic-ohci.yaml
> +++ b/Documentation/devicetree/bindings/usb/generic-ohci.yaml
> @@ -47,6 +47,7 @@ properties:
> - hpe,gxp-ohci
> - ibm,476gtr-ohci
> - ingenic,jz4740-ohci
> + - rockchip,rk3568-ohci
> - rockchip,rk3588-ohci
> - snps,hsdk-v1.0-ohci
> - const: generic-ohci
> @@ -198,7 +199,9 @@ allOf:
> properties:
> compatible:
> contains:
> - const: rockchip,rk3588-ohci
> + enum:
> + - rockchip,rk3568-ohci
> + - rockchip,rk3588-ohci
Here they clearly do have the same constraint.
Cheers,
Diederik
> then:
> properties:
> clocks:
^ permalink raw reply
* Re: [PATCH v3 3/3] ARM: dts: ti: Add specific compatibles for SCM conf nodes
From: Conor Dooley @ 2026-06-09 16:34 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, Jacky Huang,
Shan-Chun Hung, Geert Uytterhoeven, Magnus Damm, Heiko Stuebner,
Aaro Koskinen, Andreas Kemnade, Kevin Hilman, Roger Quadros,
Tony Lindgren, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, linux-renesas-soc, linux-rockchip, linux-omap
In-Reply-To: <20260608-n-dt-bindings-simple-bus-syscon-v3-3-4eba9ec1212a@oss.qualcomm.com>
[-- Attachment #1: Type: text/plain, Size: 56 bytes --]
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/4] dt-bindings: remoteproc: imx_rproc: document optional "memory-region-names"
From: Mathieu Poirier @ 2026-06-09 16:40 UTC (permalink / raw)
To: Laurentiu Mihalcea
Cc: Bjorn Andersson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Sascha Hauer, Peng Fan, Fabio Estevam, Daniel Baluta,
Francesco Dolcini, linux-remoteproc, devicetree, imx,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260605113621.1479-2-laurentiumihalcea111@gmail.com>
On Fri, Jun 05, 2026 at 04:36:18AM -0700, Laurentiu Mihalcea wrote:
> From: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
>
> The names of the carveout regions are derived using the names of the
> reserved memory devicetree nodes, which are referenced using the
> "memory-region" property. This adds a restriction on the names of said
> devicetree nodes, often bearing specific names such as: "vdevbuffer",
> "vdev0vring0", "rsc-table", etc... This goes against the devicetree
> specification's recommendation, which states that the devicetree node
> names should be generic.
I don't see what is so restrictive in using the node name of the reserved-memory
regions. Function of_reserved_mem_region_to_resource() is already doing all the
parsing, packaging everything in a neat and easy to use "struct resource". What
will you gain with this new "memory-region-names" that can't be done with the
current solution?
>
> Fix this by documenting an additional, optional property:
> "memory-region-names". This way, the carveout names can use the values
> passed via "memory-region-names", while keeping the devicetree node
> names of the reserved memory regions generic.
>
> There are no restrictions imposed on the values of the strings passed via
> the new property since the software allows any name to be used, with some
> names (e.g. "vdev%dbuffer", "vdev%dvring%d", "rsc-table") bearing a
> special meaning.
>
> Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
> ---
> .../devicetree/bindings/remoteproc/fsl,imx-rproc.yaml | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
> index c18f71b64889..8e3e6676a95e 100644
> --- a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
> +++ b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
> @@ -62,6 +62,10 @@ properties:
> minItems: 1
> maxItems: 32
>
> + memory-region-names:
> + minItems: 1
> + maxItems: 32
> +
> power-domains:
> minItems: 2
> maxItems: 8
> --
> 2.43.0
>
^ permalink raw reply
* Re: (subset) [PATCH 2/2] PCI: meson: Add missing remove callback
From: Manivannan Sadhasivam @ 2026-06-09 16:41 UTC (permalink / raw)
To: Jingoo Han, Lorenzo Pieralisi, Krzysztof Wilczyński,
Bjorn Helgaas, Yue Wang, Neil Armstrong, Shuvam Pandey
Cc: Rob Herring, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Fan Ni, Shradha Todi, Hanjie Lin, linux-pci, linux-amlogic,
linux-arm-kernel, linux-kernel
In-Reply-To: <1a0c86ab264cdc1c79c917e984b90991af51d827.1779123847.git.shuvampandey1@gmail.com>
On Mon, 18 May 2026 22:44:18 +0545, Shuvam Pandey wrote:
> meson_pcie_probe() powers on the PHY and registers the DesignWare host
> bridge with dw_pcie_host_init(), but the driver has no remove callback.
> On driver unbind or module unload, the driver core therefore proceeds to
> devres cleanup without first unregistering the host bridge or powering off
> the PHY.
>
> Add a remove callback that deinitializes the DesignWare host bridge and
> powers off the PHY while device-managed resources are still valid.
>
> [...]
Applied, thanks!
[2/2] PCI: meson: Add missing remove callback
commit: 4b0dc84b293984f75598881809fb2d3daf54a2a8
Best regards,
--
Manivannan Sadhasivam <mani@kernel.org>
^ permalink raw reply
* Re: [PATCH RFC v3 0/5] ZTE zx297520v3 clock bindings and driver
From: Stefan Dösinger @ 2026-06-09 16:42 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Brian Masney, Philipp Zabel
Cc: linux-clk, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <f92114a3658185b57bffe546c0f4079a9d39afce.camel@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 3484 bytes --]
Hi Philipp,
I did some more reading and checked past clock driver submissions. This email
is to check if I understood it right.
Am Donnerstag, 4. Juni 2026, 18:23:01 Ostafrikanische Zeit schrieb Philipp
Zabel:
> > The register lock because all LSP and at least one TOP register contains
> > both clocks and resets.
>
> That could be solved with regmap.
This will require me to change the clk component to use regmaps too. There's
no regmap equivalent to clk-{div,gate,mux}.c, so I'll need my own. qcom and
meson have similar drivers already, so I'd likely copy one of them. Is there a
particular reason why there isn't a regmap equivalent of clk-{div,gate,mux}.c?
Another hypothetical solution is a custom regmap implementation that locks my
clk driver's lock. I see that only in imx/clk-imx8ulp-sim-lpav.c.
However, the topclk region also has a stray register that controls if a
watchdog timeout resets the board. So there's no good way past a syscon
compatible and syscon generated regmap anyway.
Afaics syscon regmaps only support a single IO region, so I'd likely revert
back to the topclk/matrixclk split with different bindings, bite the other
bullet and list all 50 or so PLL outputs as clocks passed from top to matrix.
Which gives a device tree setup like this:
topcrm: something@13b000 {
compatible = "zte,zx297520v3-topcrm", "syscon", "simple-mfd";
reg = <0x0013b000 0x400>;
#address-cells = <1>;
#size-cells = <1>;
ranges;
topclk: clock-controller@0 {
compatible = "zte,zx297520v3-topclk";
reg = <0x0 0x400>;
#clock-cells = <1>;
#reset-cells = <1>;
clocks = <&osc26m>, <&osc32k>;
clock-names = "osc26m", "osc32k";
};
reboot {
compatible = "syscon-reboot";
offset = <0x0>;
mask = <0x1>;
};
};
watchdog_t18: watchdog@148000 {
compatible = "zte,zx297520-wdt";
reg = <0x00148000 0x20>;
clocks = <&topclk ZX297520V3_WDT_T18_WCLK>, <&topclk
ZX297520V3_WDT_T18_PCLK>;
clock-names = "wclk", "pclk";
resets = <&topclk ZX297520V3_WDT_T18_RESET>;
zte,wdt-reset-sysctrl = <&topcrm 0x2c 0x3 0x3>;
};
(I did not attempt to build this, might have typos)
And the reset controller will be an aux-bus child of the clock controller. I
could make the reset controller its own device with its own bindings, but that
would misrepresent the hardware.
Did I understand this correctly?
For some reason in my dev tree the reset sysctrl works even though my clock
driver does not use the syscon compatible nor manually create a regmap.
> > Shared register definition: in the case of the LSP clocks breaking up the
> > composite definition would sacrifice readability.
>
> That is a matter of perspective.
>
> I had a harder time validating that the resets[] array is properly
> initialized from the two different composite arrays because of the
> unordered reset_ids, and some remaining resets[] being filled via code.
I do have a sanity check loop for that.
> It would be much simpler if you split the reset definitions out into a
> single, separate, const array, indexed by reset id. In fact,
> I would suggest this even if you don't intend to move the reset code.
I had to collect the clocks and resets from all over ZTE's kernel and U-Boot
sources plus manual testing, so maybe I am a bit too attached to seeing all
controls for a given device in one place. If the reset controls move to a
different file, the composite structure becomes less useful, so I'll probably
split it up and just list single div, gates and regs.
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 870 bytes --]
^ permalink raw reply
* Re: (subset) [PATCH 1/2] PCI: dwc: Guard RAS DES debugfs deinit
From: Manivannan Sadhasivam @ 2026-06-09 16:44 UTC (permalink / raw)
To: Jingoo Han, Lorenzo Pieralisi, Krzysztof Wilczyński,
Bjorn Helgaas, Yue Wang, Neil Armstrong, Shuvam Pandey
Cc: Rob Herring, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Fan Ni, Shradha Todi, Hanjie Lin, linux-pci, linux-amlogic,
linux-arm-kernel, linux-kernel
In-Reply-To: <0f97352506d8d813f70f441de4d63fcd5b7d1c3e.1779123847.git.shuvampandey1@gmail.com>
On Mon, 18 May 2026 22:44:17 +0545, Shuvam Pandey wrote:
> dwc_pcie_rasdes_debugfs_init() returns success when the controller has
> no RAS DES capability, leaving pci->debugfs->rasdes_info unset. The
> common debugfs teardown path still calls
> dwc_pcie_rasdes_debugfs_deinit(), which dereferences rasdes_info
> unconditionally.
>
> Return early when no RAS DES state was allocated. In that case no RAS DES
> mutex was initialized, so there is nothing to destroy.
>
> [...]
Applied, thanks!
[1/2] PCI: dwc: Guard RAS DES debugfs deinit
commit: a5ee214bb36f43b4d8bb2615b30d3b5c0ea80826
Best regards,
--
Manivannan Sadhasivam <mani@kernel.org>
^ permalink raw reply
* [PATCH] media: bcm2835-unicam: Fix asc leaked in error/remove path
From: Eugen Hristev @ 2026-06-09 17:05 UTC (permalink / raw)
To: Raspberry Pi Kernel Maintenance, Mauro Carvalho Chehab,
Florian Fainelli, Broadcom internal kernel review list, Ray Jui,
Scott Branden, Hans Verkuil, Naushir Patuck, Sakari Ailus,
Dave Stevenson, Jean-Michel Hautbois
Cc: Laurent Pinchart, linux-media, linux-rpi-kernel, linux-arm-kernel,
linux-kernel, Eugen Hristev
v4l2_async_nf_add_fwnode_remote() allocates the asc, which is freed when
v4l2_async_nf_cleanup() is called.
Call v4l2_async_nf_cleanup() properly in the driver paths.
Discovered with kmemleak after rmmod:
unreferenced object 0xffff000084526b80 (size 64):
comm "modprobe", pid 185, jiffies 4295013512
hex dump (first 32 bytes):
01 00 00 00 00 00 00 00 e8 0d ff bf 00 00 ff ff ................
40 83 bc 84 00 00 ff ff 60 83 bc 84 00 00 ff ff @.......`.......
backtrace (crc ac584083):
[<00000000ffb081a7>] kmemleak_alloc+0x38/0x44
[<00000000d2fd9301>] __kmalloc+0x1b0/0x250
[<000000004dd5354d>] __v4l2_async_nf_add_fwnode+0x28/0x9c
[<0000000067587657>] __v4l2_async_nf_add_fwnode_remote+0x3c/0x64
Fixes: 392cd78d495f ("media: bcm2835-unicam: Add support for CCP2/CSI2 camera interface")
Signed-off-by: Eugen Hristev <ehristev@kernel.org>
---
drivers/media/platform/broadcom/bcm2835-unicam.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/media/platform/broadcom/bcm2835-unicam.c b/drivers/media/platform/broadcom/bcm2835-unicam.c
index 8d28ba0b59a3..1508843ae58c 100644
--- a/drivers/media/platform/broadcom/bcm2835-unicam.c
+++ b/drivers/media/platform/broadcom/bcm2835-unicam.c
@@ -2613,6 +2613,7 @@ static int unicam_async_nf_init(struct unicam_device *unicam)
return 0;
error:
+ v4l2_async_nf_cleanup(&unicam->notifier);
fwnode_handle_put(ep_handle);
return ret;
}
@@ -2745,6 +2746,7 @@ static void unicam_remove(struct platform_device *pdev)
v4l2_device_unregister(&unicam->v4l2_dev);
media_device_unregister(&unicam->mdev);
v4l2_async_nf_unregister(&unicam->notifier);
+ v4l2_async_nf_cleanup(&unicam->notifier);
unicam_subdev_cleanup(unicam);
---
base-commit: a87737435cfa134f9cdcc696ba3080759d04cf72
change-id: 20260609-bcmpiclean-69a8ee3192b0
Best regards,
--
Eugen Hristev <ehristev@kernel.org>
^ permalink raw reply related
* Re: [PATCH v2 1/4] dt-bindings: iio: adc: mediatek,mt6359-auxadc: add mt6323 PMIC AUXADC
From: Roman Vivchar @ 2026-06-09 17:29 UTC (permalink / raw)
To: Conor Dooley
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Lee Jones, linux-iio, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek, Ben Grisdale
In-Reply-To: <20260609-gangway-frayed-366f6d3cc867@spud>
Hi Conor,
On Tuesday, June 9th, 2026 at 7:01 PM, Conor Dooley <conor@kernel.org> wrote:
> On Tue, Jun 09, 2026 at 04:31:58PM +0300, Roman Vivchar via B4 Relay wrote:
> > properties:
> > compatible:
> > enum:
> > + - mediatek,mt6323-auxadc
>
> Commit message needs to explain why a fallback is not suitable.
> pw-bot: changes-requested
Ack.
>
> > - mediatek,mt6357-auxadc
> > - mediatek,mt6358-auxadc
> > - mediatek,mt6359-auxadc
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index d1cc0e12fe1f..2551c8cd9e9d 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -16256,6 +16256,12 @@ S: Maintained
> > F: Documentation/devicetree/bindings/mmc/mtk-sd.yaml
> > F: drivers/mmc/host/mtk-sd.c
> >
> > +MEDIATEK MT6323 PMIC AUXADC DRIVER
> > +M: Roman Vivchar <rva333@protonmail.com>
> > +L: linux-iio@vger.kernel.org
> > +S: Maintained
> > +F: include/dt-bindings/iio/adc/mediatek,mt6323-auxadc.h
>
> Why is the binding not being included here?
>
The binding is shared across multiple PMIC ADCs and maintained by
Angelo. Since I'm only familiar with mt6323 and not others like mt6358,
I decided to not include it in the mt6323 entry.
Best regards,
Roman
^ permalink raw reply
* Re: [PATCH v2 1/4] dt-bindings: remoteproc: imx_rproc: document optional "memory-region-names"
From: Mathieu Poirier @ 2026-06-09 17:33 UTC (permalink / raw)
To: Frank Li
Cc: Laurentiu Mihalcea, Bjorn Andersson, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sascha Hauer, Peng Fan,
Fabio Estevam, Daniel Baluta, Francesco Dolcini, linux-remoteproc,
devicetree, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <aihIIwt_9T7yYxP3@SMW015318>
On Tue, 9 Jun 2026 at 11:06, Frank Li <Frank.li@oss.nxp.com> wrote:
>
> On Tue, Jun 09, 2026 at 10:40:06AM -0600, Mathieu Poirier wrote:
> > [You don't often get email from mathieu.poirier@linaro.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> >
> > On Fri, Jun 05, 2026 at 04:36:18AM -0700, Laurentiu Mihalcea wrote:
> > > From: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
> > >
> > > The names of the carveout regions are derived using the names of the
> > > reserved memory devicetree nodes, which are referenced using the
> > > "memory-region" property. This adds a restriction on the names of said
> > > devicetree nodes, often bearing specific names such as: "vdevbuffer",
> > > "vdev0vring0", "rsc-table", etc... This goes against the devicetree
> > > specification's recommendation, which states that the devicetree node
> > > names should be generic.
> >
> > I don't see what is so restrictive in using the node name of the reserved-memory
> > regions. Function of_reserved_mem_region_to_resource() is already doing all the
> > parsing, packaging everything in a neat and easy to use "struct resource". What
> > will you gain with this new "memory-region-names" that can't be done with the
> > current solution?
>
> DT Binding check can't find such wrong if node name is not what expected.
> Binding can't restrict memory's node name because there ware not specific
> compatible string for it.
>
But what "wrong" could that be, and what kind of restriction are you
hoping to enforce? What specific problem are you hoping to solve?
I'll wait to see what the DT people think about this - I personally
don't see the value in it.
> Frank
>
> >
> > >
> > > Fix this by documenting an additional, optional property:
> > > "memory-region-names". This way, the carveout names can use the values
> > > passed via "memory-region-names", while keeping the devicetree node
> > > names of the reserved memory regions generic.
> > >
> > > There are no restrictions imposed on the values of the strings passed via
> > > the new property since the software allows any name to be used, with some
> > > names (e.g. "vdev%dbuffer", "vdev%dvring%d", "rsc-table") bearing a
> > > special meaning.
> > >
> > > Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
> > > ---
> > > .../devicetree/bindings/remoteproc/fsl,imx-rproc.yaml | 4 ++++
> > > 1 file changed, 4 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
> > > index c18f71b64889..8e3e6676a95e 100644
> > > --- a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
> > > +++ b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
> > > @@ -62,6 +62,10 @@ properties:
> > > minItems: 1
> > > maxItems: 32
> > >
> > > + memory-region-names:
> > > + minItems: 1
> > > + maxItems: 32
> > > +
> > > power-domains:
> > > minItems: 2
> > > maxItems: 8
> > > --
> > > 2.43.0
> > >
> >
^ permalink raw reply
* Re: [GIT PULL] ARM: mvebu: dt64 for v7.2 (#1)
From: Aleksander Jan Bajkowski @ 2026-06-09 17:35 UTC (permalink / raw)
To: Arnd Bergmann, Gregory Clement, arm, soc
Cc: Andrew Lunn, Sebastian Hesselbarth, linux-arm-kernel
In-Reply-To: <bf8092a3-d037-44ee-8e08-8b2204e5cc95@app.fastmail.com>
Hi Arnd,
On 09/06/2026 18:11, Arnd Bergmann wrote:
> On Fri, Jun 5, 2026, at 17:20, Gregory CLEMENT wrote:
>> ----------------------------------------------------------------
>> mvebu dt64 for 7.2 (part 1)
>>
>> Mark EIP97 as dma-coherent for Armada 3720
>>
>> ----------------------------------------------------------------
>> Aleksander Jan Bajkowski (1):
>> arm64: dts: marvell: armada-37xx: mark EIP97 as dma-coherent
> Hi Gregory and Aleksander,
>
> I'm a bit surprised by this oneline change. Since you successfully tested
> this, I assume the change is correct, but I have two questions that
> I would like to have an answer for before I pull it.
By the way, the upstream safexcel driver works correctly only on coherent
platforms. On non-coherent platforms (MediaTek), the SHA-384 and SHA-512
selftests fail. Since the selftests pass on Armada's SoC, I assume I'm
right.
I have a plan to send a patch upstream, which has long been maintained
downstream in OpenWRT[1]. But I need to think a bit more about how to do
this properly.
[1]
https://github.com/openwrt/openwrt/blob/main/target/linux/mediatek/patches-6.18/401-crypto-fix-eip97-cache-incoherent.patch
>
> - I would expect a missing 'dma-coherent' property to cause data
> corruption, as the DMA master may write directly into the L2
> cache, which is then invalidated before the CPU accesses it.
> Do you have any idea how this one ends up working even when
> the property is missing?
No idea. Don't have access the Armada SoC TRM. Maybe the folks at
Marvel will be able to explain it.
>
> - I see that the Product Brief for Armada 37xx mentions that it
> has a "High-bandwidth, low-latency IO Cache Coherency" interconnect,
> which also indicates that the patch is correct. However I don't
> see why it's only the crypto engine that needs it. What about
> the other high-speed DMA masters (neta, xhci, pcie, sata, ...)?
I didn't test to determine whether the other DMA masters are coherent.
But I'm assuming you're correct and they are also coherent. My recent
work has been focused on improving the Rambus/Verimatrix/Safenet crypto
drivers :)
Best regards,
Aleksander
^ permalink raw reply
* [PATCH v5 0/6] Exynos-pmu: Generalise cpu{hotplug,idle},PMU intr gen and add Exynos850 CPU hotplug
From: Alexey Klimov @ 2026-06-09 17:39 UTC (permalink / raw)
To: Sam Protsenko, linux-samsung-soc, Krzysztof Kozlowski,
Peter Griffin
Cc: linux-samsung-soc, André Draszik, Tudor Ambarus, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Alim Akhtar, Henrik Grimler,
linux-arm-kernel, devicetree, linux-kernel
Series generalises the GS101-specific cpuhotplug, cpuidle and PMU interrupt
generation block support, which is currently implemented specifically for
the google GS101 SoC, to make it reusable by other Samsung Exynos SoCs.
The PMU interrupt generation IP block introduced for google GS101 is a
standard Samsung Exynos block found in other SoCs, including Exynos850,
and it is not strictly exclusive to google Exynos-based platforms.
Access to this block is required to implement and enable cpuhotplug
on Exynos850-based boards.
As a next steps it will be possible to enable idle states on top of it
(if we get our hands on corrected firmware).
First patches work on DT bindings to reflect that Exynos850 SoC predates
gs101 one and adding mandatory property 'google,pmu-intr-gen-syscon'
for exynos850-pmu.
Then series generalises ("Exynosizes") cpuhotplug/cpuidle routines by
deferring platform-specific PMU and PMU-intr-gen updates to platform-
specific callbacks and then finally introduces new file exynos850-pmu.c
where such callbacks are implemented for Exynos850. Last commit adds
pmu_intr_gen DT node to exynos850.dtsi.
This series wants Exynos PMU "fixes" series first to make Sashiko bot
happy. This "dependency" describes sequential order of commits.
https://lore.kernel.org/linux-samsung-soc/20260605-exynos-pmu-cpuhp-idle-fixes-v1-0-0cd05c81a82d@linaro.org/
The main updates are custom regmap for pmu regs to support PREEMPT_RT
cases -- we need raw_spinlocks there, minor adjustments in exynos850-pmu.c
and "fixes" series mostly reported by Sashiko bot here:
https://sashiko.dev/#/patchset/20260513-exynos850-cpuhotplug-v4-0-54fec5f65362@linaro.org?part=4
This series was re-tested on Exynos850 WinLink E850-96 board:
-- by spinning "chcpu -d 1-7; chcpu -e 1-7" in a loop for a few hours;
-- by running script [1] that randomly offlines or onlines random cpus
for a few hours.
I tried to implement it in way to not break anything for gs101, thanks to
Peter for testing.
Thanks,
Alexey
[1]: https://github.com/laklimov/xlam/blob/main/e850_cpuhotplug_random.sh
Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
---
Changes in v5:
- updated the commit message of ("soc: samsung: exynos-pmu: add Exynos850
CPU hotplug support");
- the if-check for the presense of pmu_data->cpu_pmu_{offline,online}
callbacks in setup_cpuhp_and_cpuidle() was moved to before acquiring ref
counter to intr_gen_node (the initial issue was reported by Sashiko);
- added pr_fmt to exynos850-pmu.c to have more meaningful error
messages;
- added parentheses around the `cl` in `EXYNOS850_CLUSTER_CPU_OFFSET` macro
(as suggested by Sashiko bot);
- custom syscon regmap with raw_spinlocks for pmu offline/online callbacks
(the initial issue was reported by Sashiko);
- using topology_cluster_id() and topology_core_id() in exynos850-pmu.c
(the initial issue was reported by Sashiko);
- removed smp_processor_id() usage fomr pmu offline/online callbacks
(the initial issue was reported by Sashiko);
- added/resorted headers in exynos850-pmu.c;
- Link to v4: https://lore.kernel.org/r/20260513-exynos850-cpuhotplug-v4-0-54fec5f65362@linaro.org
Changes in v4:
- remove blank line in file exynos850-pmu.c, commit (as suggested by Krzysztof);
- only update trailers/tags in commit messages;
- Link to v3: https://lore.kernel.org/r/20260430-exynos850-cpuhotplug-v3-0-fd6251d02a17@linaro.org
Changes in v3:
- dropped two commits where samsung,pmu-intr-gen phandle is introduced and
where google,pmu-intr-gen-syscon is deprecated (as suggested by Rob Herring);
- addtion to maintainers file was moved to separate entry, change commit message;
- commit message in "generalise gs101-specific cpu{idle,hotplug} for Exynos SoCs"
was updated since it no longer touches samsung,pmu-intr-gen-syscon;
- added missing asm/cputype.h header to exynos850-pmu.h
(reported by Henrik Grimler);
- new commit "dt-bindings: soc: samsung: exynos-pmu: Require
pmu-intr-gen-syscon for Exynos850";
- Link to v2: https://lore.kernel.org/r/20260401-exynos850-cpuhotplug-v2-0-c5a760a3e259@linaro.org
Changes in v2:
- moved gs101 cpu {offline,online} callbacks to gs101-pmu.c, updated MAINTAINERS;
- added new file exynos850-pmu.c with cpu {offline,online} callbacks and
exynos850 pmu data;
- new patch that adds exynos850-pmu.c to MAINTAINERS;
- moved pmu_intr_gen to right after pmu_system_controller@11860000;
- merged two patches that update google,gs101-pmu-intr-gen.yaml together,
now rename and adding exynos850 entry goes in a single patch;
- commits 5 and 6 from RFC series are merged together and reworked,
cpu_pmu_{offline,online} callbacks are moved into pmu_data struct, and
callbacks now need pmu_context as an argument, exynos_pmu_context and
CPU_INFORM defines are moved to exynos-pmu.h, gs101 callbacks
renamed. It is really better to check commit description.
- Link to RFC (v1 from b4 point of view):
https://lore.kernel.org/r/20260226-exynos850-cpuhotplug-v1-0-71d7c4063382@linaro.org
---
Alexey Klimov (6):
dt-bindings: soc: move,rename google,gs101-pmu-intr-gen and add exynos850
dt-bindings: soc: samsung: exynos-pmu: Require pmu-intr-gen-syscon for Exynos850
soc: samsung: exynos-pmu: generalise gs101-specific cpu{idle,hotplug} for Exynos SoCs
soc: samsung: exynos-pmu: add Exynos850 CPU hotplug support
MAINTAINERS: add Exynos850 PMU entry
arm64: dts: exynos850: add PMU interrupt generation node
.../bindings/soc/samsung/exynos-pmu.yaml | 1 +
.../samsung,exynos850-pmu-intr-gen.yaml} | 8 +-
MAINTAINERS | 9 +-
arch/arm64/boot/dts/exynos/exynos850.dtsi | 6 +
drivers/soc/samsung/Makefile | 2 +-
drivers/soc/samsung/exynos-pmu.c | 146 +++++++--------------
drivers/soc/samsung/exynos-pmu.h | 34 +++++
drivers/soc/samsung/exynos850-pmu.c | 95 ++++++++++++++
drivers/soc/samsung/gs101-pmu.c | 49 +++++++
include/linux/soc/samsung/exynos-regs-pmu.h | 15 ++-
10 files changed, 258 insertions(+), 107 deletions(-)
---
base-commit: e98d21c170b01ddef366f023bbfcf6b31509fa83
change-id: 20260226-exynos850-cpuhotplug-69f1976eefa8
prerequisite-message-id: 20260605-exynos-pmu-cpuhp-idle-fixes-v1-0-0cd05c81a82d@linaro.org
prerequisite-patch-id: a36b838f6524b89818ead01648e27177f002b1b1
prerequisite-patch-id: 85901b4ed10abf67809a9f28bd2be52356f93526
prerequisite-patch-id: 6e4d2217a7231375df85a12910badb8b2b8e1fd6
Best regards,
--
Alexey Klimov <alexey.klimov@linaro.org>
^ permalink raw reply
* [PATCH v5 1/6] dt-bindings: soc: move,rename google,gs101-pmu-intr-gen and add exynos850
From: Alexey Klimov @ 2026-06-09 17:39 UTC (permalink / raw)
To: Sam Protsenko, linux-samsung-soc, Krzysztof Kozlowski,
Peter Griffin
Cc: linux-samsung-soc, André Draszik, Tudor Ambarus, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Alim Akhtar, Henrik Grimler,
linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260609-exynos850-cpuhotplug-v5-0-8422cf80d43b@linaro.org>
The PMU interrupt generation block introduced for the Google GS101 is
actually a standard Samsung Exynos IP block found in older SoCs, such
as the Exynos850, and is not exclusive to Google SoCs. To accurately
reflect its origin, move the schema file to under soc/samsung/
directory and rename it.
Concurrently, add the new "samsung,exynos850-pmu-intr-gen" compatible
string to the bindings. Support for this block is required to enable
power management features like CPU hotplug and idle states on Exynos850
platforms.
Also, move this file under Exynos850 SoC in MAINTAINERS entry.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
---
.../samsung,exynos850-pmu-intr-gen.yaml} | 8 +++++---
MAINTAINERS | 2 +-
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/soc/google/google,gs101-pmu-intr-gen.yaml b/Documentation/devicetree/bindings/soc/samsung/samsung,exynos850-pmu-intr-gen.yaml
similarity index 70%
rename from Documentation/devicetree/bindings/soc/google/google,gs101-pmu-intr-gen.yaml
rename to Documentation/devicetree/bindings/soc/samsung/samsung,exynos850-pmu-intr-gen.yaml
index 2be022ca6a7d..df23467d0e0e 100644
--- a/Documentation/devicetree/bindings/soc/google/google,gs101-pmu-intr-gen.yaml
+++ b/Documentation/devicetree/bindings/soc/samsung/samsung,exynos850-pmu-intr-gen.yaml
@@ -1,10 +1,10 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: http://devicetree.org/schemas/soc/google/google,gs101-pmu-intr-gen.yaml#
+$id: http://devicetree.org/schemas/soc/samsung/samsung,exynos850-pmu-intr-gen.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Google Power Management Unit (PMU) Interrupt Generation
+title: Samsung Power Management Unit (PMU) Interrupt Generation
description: |
PMU interrupt generator for handshaking between PMU through interrupts.
@@ -15,7 +15,9 @@ maintainers:
properties:
compatible:
items:
- - const: google,gs101-pmu-intr-gen
+ - enum:
+ - google,gs101-pmu-intr-gen
+ - samsung,exynos850-pmu-intr-gen
- const: syscon
reg:
diff --git a/MAINTAINERS b/MAINTAINERS
index 86ca9297edab..498ca30a00c5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10952,7 +10952,6 @@ P: Documentation/process/maintainer-soc-clean-dts.rst
C: irc://irc.oftc.net/pixel6-kernel-dev
F: Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
F: Documentation/devicetree/bindings/phy/google,lga-usb-phy.yaml
-F: Documentation/devicetree/bindings/soc/google/google,gs101-pmu-intr-gen.yaml
F: Documentation/devicetree/bindings/usb/google,lga-dwc3.yaml
F: arch/arm64/boot/dts/exynos/google/
F: drivers/clk/samsung/clk-gs101.c
@@ -23652,6 +23651,7 @@ L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
L: linux-samsung-soc@vger.kernel.org
S: Maintained
F: Documentation/devicetree/bindings/clock/samsung,exynos850-clock.yaml
+F: Documentation/devicetree/bindings/soc/samsung/samsung,exynos850-pmu-intr-gen.yaml
F: arch/arm64/boot/dts/exynos/exynos850*
F: drivers/clk/samsung/clk-exynos850.c
F: include/dt-bindings/clock/exynos850.h
--
2.51.0
^ permalink raw reply related
* [PATCH v5 2/6] dt-bindings: soc: samsung: exynos-pmu: Require pmu-intr-gen-syscon for Exynos850
From: Alexey Klimov @ 2026-06-09 17:39 UTC (permalink / raw)
To: Sam Protsenko, linux-samsung-soc, Krzysztof Kozlowski,
Peter Griffin
Cc: linux-samsung-soc, André Draszik, Tudor Ambarus, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Alim Akhtar, Henrik Grimler,
linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260609-exynos850-cpuhotplug-v5-0-8422cf80d43b@linaro.org>
Update the Exynos PMU schema to mandate the 'google,pmu-intr-gen-syscon'
property for the 'samsung,exynos850-pmu' compatible so the driver can
obtain the necessary syscon regmap.
The Exynos850 PMU relies on a separate system controller block to handle
interrupts generation, similar to the hardware design of the GS101
SoC. To ensure the hardware is correctly described, this syscon phandle
must be explicitly provided.
Reviewed-by: Peter Griffin <peter.griffin@linaro.org>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
---
Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml b/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml
index 76ce7e98c10f..6550c3736a3b 100644
--- a/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml
+++ b/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml
@@ -182,6 +182,7 @@ allOf:
contains:
enum:
- google,gs101-pmu
+ - samsung,exynos850-pmu
then:
required:
- google,pmu-intr-gen-syscon
--
2.51.0
^ permalink raw reply related
* [PATCH v5 3/6] soc: samsung: exynos-pmu: generalise gs101-specific cpu{idle,hotplug} for Exynos SoCs
From: Alexey Klimov @ 2026-06-09 17:39 UTC (permalink / raw)
To: Sam Protsenko, linux-samsung-soc, Krzysztof Kozlowski,
Peter Griffin
Cc: linux-samsung-soc, André Draszik, Tudor Ambarus, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Alim Akhtar, Henrik Grimler,
linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260609-exynos850-cpuhotplug-v5-0-8422cf80d43b@linaro.org>
The cpuhotplug and cpuidle support for GS101-based SoCs which
utilizes GS101 PMU interrupts generation block can be generalised
to be (re)used for other Exynos-based SoCs. Also, the GS101 PMU
interrupts generation block is not exclusive to Google GS101 SoCs
and should be made more Exynos-generic.
Specifically, apply the following changes:
- rename gs101-specific calls, structs, names to be exynos-prefixed;
- move exynos_pmu_context and CPU_INFORM_* defines into exynos-pmu.h;
- introduce cpu_pmu_{offline,online} callbacks in driver-specific
exynos_pmu_data which can be used to hold PMU and PMU intr gen
update routines for different platforms and update cpuidle and cpuhotplug
support to use them;
- add checks for the presense of cpu_pmu_{offline,online} callbacks;
- move and rename gs101-specific cpu{offline,online} PMU updates
routines into gs101-pmu.c file, also removing underscore prefix;
- update gs101_pmu_data to use newly introduced callbacks;
- rename PMU interrupts generation GS101_INTR_* regs to EXYNOS_INTR_*.
This allows other platforms to add cpuhotplug and cpuidle support in
a similar manner, using their own platform-specific PMU and
PMU intr gen update routines.
Reviewed-by: Peter Griffin <peter.griffin@linaro.org>
Tested-by: Peter Griffin <peter.griffin@linaro.org>
Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
---
drivers/soc/samsung/exynos-pmu.c | 122 ++++++----------------------
drivers/soc/samsung/exynos-pmu.h | 33 ++++++++
drivers/soc/samsung/gs101-pmu.c | 49 +++++++++++
include/linux/soc/samsung/exynos-regs-pmu.h | 10 +--
4 files changed, 112 insertions(+), 102 deletions(-)
diff --git a/drivers/soc/samsung/exynos-pmu.c b/drivers/soc/samsung/exynos-pmu.c
index 846313a28e9a..f170abe08ef1 100644
--- a/drivers/soc/samsung/exynos-pmu.c
+++ b/drivers/soc/samsung/exynos-pmu.c
@@ -24,24 +24,6 @@
#include "exynos-pmu.h"
-struct exynos_pmu_context {
- struct device *dev;
- const struct exynos_pmu_data *pmu_data;
- struct regmap *pmureg;
- struct regmap *pmuintrgen;
- /*
- * Serialization lock for CPU hot plug and cpuidle ACPM hint
- * programming. Also protects in_cpuhp, sys_insuspend & sys_inreboot
- * flags.
- */
- raw_spinlock_t cpupm_lock;
- unsigned long *in_cpuhp;
- bool sys_insuspend;
- bool sys_inreboot;
- int cpuhp_prepare_state;
- int cpuhp_online_state;
-};
-
void __iomem *pmu_base_addr;
static struct exynos_pmu_context *pmu_context;
/* forward declaration */
@@ -221,43 +203,8 @@ struct regmap *exynos_get_pmu_regmap_by_phandle(struct device_node *np,
}
EXPORT_SYMBOL_GPL(exynos_get_pmu_regmap_by_phandle);
-/*
- * CPU_INFORM register "hint" values are required to be programmed in addition to
- * the standard PSCI calls to have functional CPU hotplug and CPU idle states.
- * This is required to workaround limitations in the el3mon/ACPM firmware.
- */
-#define CPU_INFORM_CLEAR 0
-#define CPU_INFORM_C2 1
-
-/*
- * __gs101_cpu_pmu_ prefix functions are common code shared by CPU PM notifiers
- * (CPUIdle) and CPU hotplug callbacks. Functions should be called with IRQs
- * disabled and cpupm_lock held.
- */
-static int __gs101_cpu_pmu_online(unsigned int cpu)
- __must_hold(&pmu_context->cpupm_lock)
-{
- u32 reg, mask;
-
- /* clear cpu inform hint */
- regmap_write(pmu_context->pmureg, GS101_CPU_INFORM(cpu),
- CPU_INFORM_CLEAR);
-
- mask = BIT(cpu);
-
- regmap_update_bits(pmu_context->pmuintrgen, GS101_GRP2_INTR_BID_ENABLE,
- mask, (0 << cpu));
-
- regmap_read(pmu_context->pmuintrgen, GS101_GRP2_INTR_BID_UPEND, ®);
-
- regmap_write(pmu_context->pmuintrgen, GS101_GRP2_INTR_BID_CLEAR,
- reg & mask);
-
- return 0;
-}
-
/* Called from CPU PM notifier (CPUIdle code path) with IRQs disabled */
-static int gs101_cpu_pmu_online(void)
+static int exynos_cpu_pmu_online(void)
{
int cpu;
@@ -269,20 +216,20 @@ static int gs101_cpu_pmu_online(void)
}
cpu = smp_processor_id();
- __gs101_cpu_pmu_online(cpu);
+ pmu_context->pmu_data->cpu_pmu_online(pmu_context, cpu);
raw_spin_unlock(&pmu_context->cpupm_lock);
return NOTIFY_OK;
}
/* Called from CPU hot plug callback with IRQs enabled */
-static int gs101_cpuhp_pmu_online(unsigned int cpu)
+static int exynos_cpuhp_pmu_online(unsigned int cpu)
{
unsigned long flags;
raw_spin_lock_irqsave(&pmu_context->cpupm_lock, flags);
- __gs101_cpu_pmu_online(cpu);
+ pmu_context->pmu_data->cpu_pmu_online(pmu_context, cpu);
/*
* Mark this CPU as having finished the hotplug.
* This means this CPU can now enter C2 idle state.
@@ -293,33 +240,8 @@ static int gs101_cpuhp_pmu_online(unsigned int cpu)
return 0;
}
-/* Common function shared by both CPU hot plug and CPUIdle */
-static int __gs101_cpu_pmu_offline(unsigned int cpu)
- __must_hold(&pmu_context->cpupm_lock)
-{
- u32 reg, mask;
-
- /* set cpu inform hint */
- regmap_write(pmu_context->pmureg, GS101_CPU_INFORM(cpu), CPU_INFORM_C2);
-
- mask = BIT(cpu);
- regmap_update_bits(pmu_context->pmuintrgen, GS101_GRP2_INTR_BID_ENABLE,
- mask, BIT(cpu));
-
- regmap_read(pmu_context->pmuintrgen, GS101_GRP1_INTR_BID_UPEND, ®);
- regmap_write(pmu_context->pmuintrgen, GS101_GRP1_INTR_BID_CLEAR,
- reg & mask);
-
- mask = (BIT(cpu + 8));
- regmap_read(pmu_context->pmuintrgen, GS101_GRP1_INTR_BID_UPEND, ®);
- regmap_write(pmu_context->pmuintrgen, GS101_GRP1_INTR_BID_CLEAR,
- reg & mask);
-
- return 0;
-}
-
/* Called from CPU PM notifier (CPUIdle code path) with IRQs disabled */
-static int gs101_cpu_pmu_offline(void)
+static int exynos_cpu_pmu_offline(void)
{
int cpu;
@@ -337,14 +259,14 @@ static int gs101_cpu_pmu_offline(void)
return NOTIFY_OK;
}
- __gs101_cpu_pmu_offline(cpu);
+ pmu_context->pmu_data->cpu_pmu_offline(pmu_context, cpu);
raw_spin_unlock(&pmu_context->cpupm_lock);
return NOTIFY_OK;
}
/* Called from CPU hot plug callback with IRQs enabled */
-static int gs101_cpuhp_pmu_offline(unsigned int cpu)
+static int exynos_cpuhp_pmu_offline(unsigned int cpu)
{
unsigned long flags;
@@ -354,29 +276,29 @@ static int gs101_cpuhp_pmu_offline(unsigned int cpu)
* ACPM the CPU entering hotplug should not enter C2 idle state.
*/
set_bit(cpu, pmu_context->in_cpuhp);
- __gs101_cpu_pmu_offline(cpu);
+ pmu_context->pmu_data->cpu_pmu_offline(pmu_context, cpu);
raw_spin_unlock_irqrestore(&pmu_context->cpupm_lock, flags);
return 0;
}
-static int gs101_cpu_pm_notify_callback(struct notifier_block *self,
+static int exynos_cpu_pm_notify_callback(struct notifier_block *self,
unsigned long action, void *v)
{
switch (action) {
case CPU_PM_ENTER:
- return gs101_cpu_pmu_offline();
+ return exynos_cpu_pmu_offline();
case CPU_PM_EXIT:
- return gs101_cpu_pmu_online();
+ return exynos_cpu_pmu_online();
}
return NOTIFY_OK;
}
-static struct notifier_block gs101_cpu_pm_notifier = {
- .notifier_call = gs101_cpu_pm_notify_callback,
+static struct notifier_block exynos_cpu_pm_notifier = {
+ .notifier_call = exynos_cpu_pm_notify_callback,
/*
* We want to be called first, as the ACPM hint and handshake is what
* puts the CPU into C2.
@@ -408,7 +330,7 @@ static struct notifier_block exynos_cpupm_reboot_nb = {
static void destroy_cpuhp_and_cpuidle(void)
{
- cpu_pm_unregister_notifier(&gs101_cpu_pm_notifier);
+ cpu_pm_unregister_notifier(&exynos_cpu_pm_notifier);
unregister_reboot_notifier(&exynos_cpupm_reboot_nb);
if (pmu_context->cpuhp_prepare_state != CPUHP_INVALID)
@@ -424,6 +346,12 @@ static int setup_cpuhp_and_cpuidle(struct device *dev)
void __iomem *virt_addr;
int ret, cpu;
+ if (!pmu_context->pmu_data->cpu_pmu_offline || !pmu_context->pmu_data->cpu_pmu_online) {
+ dev_err(dev,
+ "PMU write/update sequence is not present for cpuhotplug and cpuidle\n");
+ return -ENODEV;
+ }
+
intr_gen_node = of_parse_phandle(dev->of_node,
"google,pmu-intr-gen-syscon", 0);
if (!intr_gen_node) {
@@ -475,28 +403,28 @@ static int setup_cpuhp_and_cpuidle(struct device *dev)
/* set PMU to power on */
for_each_online_cpu(cpu)
- gs101_cpuhp_pmu_online(cpu);
+ exynos_cpuhp_pmu_online(cpu);
/* register CPU hotplug callbacks */
pmu_context->cpuhp_prepare_state = CPUHP_INVALID;
pmu_context->cpuhp_online_state = CPUHP_INVALID;
ret = cpuhp_setup_state(CPUHP_BP_PREPARE_DYN, "soc/exynos-pmu:prepare",
- gs101_cpuhp_pmu_online, NULL);
+ exynos_cpuhp_pmu_online, NULL);
if (ret < 0)
return ret;
pmu_context->cpuhp_prepare_state = ret;
ret = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "soc/exynos-pmu:online",
- NULL, gs101_cpuhp_pmu_offline);
+ NULL, exynos_cpuhp_pmu_offline);
if (ret < 0)
goto clean_cpuhp_states;
pmu_context->cpuhp_online_state = ret;
/* register CPU PM notifiers for cpuidle */
- ret = cpu_pm_register_notifier(&gs101_cpu_pm_notifier);
+ ret = cpu_pm_register_notifier(&exynos_cpu_pm_notifier);
if (ret)
goto clean_cpuhp_states;
@@ -505,7 +433,7 @@ static int setup_cpuhp_and_cpuidle(struct device *dev)
/* Success */
return ret;
- cpu_pm_unregister_notifier(&gs101_cpu_pm_notifier);
+ cpu_pm_unregister_notifier(&exynos_cpu_pm_notifier);
clean_cpuhp_states:
if (pmu_context->cpuhp_prepare_state != CPUHP_INVALID)
diff --git a/drivers/soc/samsung/exynos-pmu.h b/drivers/soc/samsung/exynos-pmu.h
index fbe381e2a2e1..733e188fa2b1 100644
--- a/drivers/soc/samsung/exynos-pmu.h
+++ b/drivers/soc/samsung/exynos-pmu.h
@@ -13,6 +13,14 @@
#define PMU_TABLE_END (-1U)
+/*
+ * CPU_INFORM register "hint" values are required to be programmed in addition to
+ * the standard PSCI calls to have functional CPU hotplug and CPU idle states.
+ * This is required to workaround limitations in the el3mon/ACPM firmware.
+ */
+#define CPU_INFORM_CLEAR 0
+#define CPU_INFORM_C2 1
+
struct regmap_access_table;
struct exynos_pmu_conf {
@@ -20,6 +28,24 @@ struct exynos_pmu_conf {
u8 val[NUM_SYS_POWERDOWN];
};
+struct exynos_pmu_context {
+ struct device *dev;
+ const struct exynos_pmu_data *pmu_data;
+ struct regmap *pmureg;
+ struct regmap *pmuintrgen;
+ /*
+ * Serialization lock for CPU hot plug and cpuidle ACPM hint
+ * programming. Also protects in_cpuhp, sys_insuspend & sys_inreboot
+ * flags.
+ */
+ raw_spinlock_t cpupm_lock;
+ unsigned long *in_cpuhp;
+ bool sys_insuspend;
+ bool sys_inreboot;
+ int cpuhp_prepare_state;
+ int cpuhp_online_state;
+};
+
/**
* struct exynos_pmu_data - of_device_id (match) data
*
@@ -44,6 +70,10 @@ struct exynos_pmu_conf {
* used (i.e. when @pmu_secure is @true).
* @wr_table: A table of writable register ranges in case a custom regmap is
* used (i.e. when @pmu_secure is @true).
+ * @cpu_pmu_offline: Optional callback to be called before entering CPU offline
+ * or idle state. Only valid when pmu_cpuhp set to true.
+ * @cpu_pmu_online: Optional callback to be called after CPU onlined or after
+ * exiting idle state. Only valid when pmu_cpuhp set to true.
*/
struct exynos_pmu_data {
const struct exynos_pmu_conf *pmu_config;
@@ -57,6 +87,9 @@ struct exynos_pmu_data {
const struct regmap_access_table *rd_table;
const struct regmap_access_table *wr_table;
+
+ int (*cpu_pmu_offline)(struct exynos_pmu_context *pmu_context, unsigned int cpu);
+ int (*cpu_pmu_online)(struct exynos_pmu_context *pmu_context, unsigned int cpu);
};
extern void __iomem *pmu_base_addr;
diff --git a/drivers/soc/samsung/gs101-pmu.c b/drivers/soc/samsung/gs101-pmu.c
index 17dadc1b9c6e..ec75ff062ce0 100644
--- a/drivers/soc/samsung/gs101-pmu.c
+++ b/drivers/soc/samsung/gs101-pmu.c
@@ -322,11 +322,60 @@ static const struct regmap_access_table gs101_pmu_wr_table = {
.n_no_ranges = ARRAY_SIZE(gs101_pmu_ro_registers),
};
+/*
+ * gs101_cpu_pmu_ prefix functions are common code shared by CPU PM notifiers
+ * (CPUIdle) and CPU hotplug callbacks. Functions should be called with IRQs
+ * disabled and cpupm_lock held.
+ */
+static int gs101_cpu_pmu_online(struct exynos_pmu_context *pmu_context, unsigned int cpu)
+ __must_hold(&pmu_context->cpupm_lock)
+{
+ u32 reg, mask;
+
+ /* clear cpu inform hint */
+ regmap_write(pmu_context->pmureg, GS101_CPU_INFORM(cpu), CPU_INFORM_CLEAR);
+
+ mask = BIT(cpu);
+ regmap_update_bits(pmu_context->pmuintrgen, EXYNOS_GRP2_INTR_BID_ENABLE,
+ mask, (0 << cpu));
+
+ regmap_read(pmu_context->pmuintrgen, EXYNOS_GRP2_INTR_BID_UPEND, ®);
+
+ regmap_write(pmu_context->pmuintrgen, EXYNOS_GRP2_INTR_BID_CLEAR, reg & mask);
+
+ return 0;
+}
+
+/* Common function shared by both CPU hot plug and CPUIdle */
+static int gs101_cpu_pmu_offline(struct exynos_pmu_context *pmu_context, unsigned int cpu)
+ __must_hold(&pmu_context->cpupm_lock)
+{
+ u32 reg, mask;
+
+ /* set cpu inform hint */
+ regmap_write(pmu_context->pmureg, GS101_CPU_INFORM(cpu), CPU_INFORM_C2);
+
+ mask = BIT(cpu);
+ regmap_update_bits(pmu_context->pmuintrgen, EXYNOS_GRP2_INTR_BID_ENABLE,
+ mask, BIT(cpu));
+
+ regmap_read(pmu_context->pmuintrgen, EXYNOS_GRP1_INTR_BID_UPEND, ®);
+ regmap_write(pmu_context->pmuintrgen, EXYNOS_GRP1_INTR_BID_CLEAR, reg & mask);
+
+ mask = (BIT(cpu + 8));
+ regmap_read(pmu_context->pmuintrgen, EXYNOS_GRP1_INTR_BID_UPEND, ®);
+ regmap_write(pmu_context->pmuintrgen, EXYNOS_GRP1_INTR_BID_CLEAR, reg & mask);
+
+ return 0;
+}
+
const struct exynos_pmu_data gs101_pmu_data = {
.pmu_secure = true,
.pmu_cpuhp = true,
.rd_table = &gs101_pmu_rd_table,
.wr_table = &gs101_pmu_wr_table,
+ .cpu_pmu_offline = gs101_cpu_pmu_offline,
+ .cpu_pmu_online = gs101_cpu_pmu_online,
};
/*
diff --git a/include/linux/soc/samsung/exynos-regs-pmu.h b/include/linux/soc/samsung/exynos-regs-pmu.h
index db8a7ca81080..9c4d3da41dbf 100644
--- a/include/linux/soc/samsung/exynos-regs-pmu.h
+++ b/include/linux/soc/samsung/exynos-regs-pmu.h
@@ -1009,11 +1009,11 @@
#define GS101_PHY_CTRL_UFS 0x3ec8
/* PMU INTR GEN */
-#define GS101_GRP1_INTR_BID_UPEND (0x0108)
-#define GS101_GRP1_INTR_BID_CLEAR (0x010c)
-#define GS101_GRP2_INTR_BID_ENABLE (0x0200)
-#define GS101_GRP2_INTR_BID_UPEND (0x0208)
-#define GS101_GRP2_INTR_BID_CLEAR (0x020c)
+#define EXYNOS_GRP1_INTR_BID_UPEND (0x0108)
+#define EXYNOS_GRP1_INTR_BID_CLEAR (0x010c)
+#define EXYNOS_GRP2_INTR_BID_ENABLE (0x0200)
+#define EXYNOS_GRP2_INTR_BID_UPEND (0x0208)
+#define EXYNOS_GRP2_INTR_BID_CLEAR (0x020c)
/* exynosautov920 */
#define EXYNOSAUTOV920_PHY_CTRL_USB20 (0x0710)
--
2.51.0
^ permalink raw reply related
* [PATCH v5 5/6] MAINTAINERS: add Exynos850 PMU entry
From: Alexey Klimov @ 2026-06-09 17:39 UTC (permalink / raw)
To: Sam Protsenko, linux-samsung-soc, Krzysztof Kozlowski,
Peter Griffin
Cc: linux-samsung-soc, André Draszik, Tudor Ambarus, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Alim Akhtar, Henrik Grimler,
linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260609-exynos850-cpuhotplug-v5-0-8422cf80d43b@linaro.org>
Add Exynos850 PMU entry describing new file
drivers/soc/samsung/exynos850-pmu.c.
Add myself as M there since I contributed Exynos850
PMU support and intend to maintain that.
Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
---
MAINTAINERS | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 498ca30a00c5..60c25fed8ffa 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -23645,6 +23645,13 @@ F: arch/arm64/boot/dts/exynos/exynos2200*
F: drivers/clk/samsung/clk-exynos2200.c
F: include/dt-bindings/clock/samsung,exynos2200-cmu.h
+SAMSUNG EXYNOS850 PMU SUPPORT
+M: Alexey Klimov <alexey.klimov@linaro.org>
+L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
+L: linux-samsung-soc@vger.kernel.org
+S: Maintained
+F: drivers/soc/samsung/exynos850-pmu.c
+
SAMSUNG EXYNOS850 SoC SUPPORT
M: Sam Protsenko <semen.protsenko@linaro.org>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
--
2.51.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox